If I understood your idea correctly, you basically just run some very limited kernel code on a dedicated core with all unrelated interrupts etc. disabled?
That seems so limited that it has not much practical use. Biggest problems are that it can't run user code and that any communication with other cores easily breaks the real-time guarantuee.
- 1us accurate timer.
Standard gettimeofday gives me that. The system has plenty very accurate timers, the problem is transferring that info fast enough to where it's needed.
- Firewall/routing/etc. offloading.
This is totally real-time unrelated. Basically it wastes one whole core on doing that instead of letting that core do also other things, and adds extra communication overhead between cores/subsystems (still need to get the packets from somewhere and tell which ones go where etc). It seems the same can be achieved by pinning the NIC interrupts to one core and giving all network related stuff highest priority.
You basically replace standard processes with very limited kernel code running on dedicated core. I don't say this is a bad idea in itself, but for this to make sense you want to have many (independent, low power) cores. I suspect that PC hardware isn't very suitable for this, because too much is shared by cores. It probably makes more sense for embedded systems, but even there it's questionable because of the kernel code only limitation.
What's the advantage of offsched compared to running a user space process at real-time priority pinned on a core with interrupts disabled?
Or in other words, what problem does your approach solve?