Re: Van Jacobson's net channels and real-time

On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which shouldn't wait for cachelines from other cpus
too much.

Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.

In the meantime I would reduce the effects with only committing
on full buffer or on leaving the interrupt handler.

This would be ok, because here you have to wakeup the process
anyway on full buffer and if it slept because of empty buffer.

You loose only, if your application didn't sleep yet and you need to
leave the interrupt handler because there is no work anymore.
In this case the atomic_add would be significant.

All this is quite similiar to now we do page_vec stuff in mm/ already.


Regards

Ingo Oeser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Van Jacobsons net channels and real-time
    ... little burden on the bottlenecks as possible. ... It is not clear that MSI'ing the RX interrupt to multiple cpus is the ... Consider the fact that by doing so you're reducing the amount of batch ...
    (Linux-Kernel)
  • Re: Van Jacobsons net channels and real-time
    ... little burden on the bottlenecks as possible. ... which shouldn't wait for cachelines from other cpus ... MSI-X will allow much better interrupt handling across several cpu's. ...
    (Linux-Kernel)
  • [PATCH] spelling fixes: kernel/
    ... + * Temporarily set tasks mems_allowed to target nodes of migration, ... static void delayacct_end(struct timespec *start, struct timespec *end, ... @desc: description of the interrupt ... + * as new CPUs are detected in the system via any platform specific ...
    (Linux-Kernel)
  • Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
    ... CPUs do optimize this quite well, but it is true that not every CPU ... I was told a while back not to use indirect pointers for some ... The FRV CPU, like many others, supports interrupt prioritisation. ... the prioritization is rarely integrated with the CPU ...
    (Linux-Kernel)
  • Re: 2.6.11-rc1-mm1
    ... the only way this will fail is if an interrupt occurred ... index value needs to get reloaded from memory each time around the loop. ... > Frankly this is legacy code for when ltt only supported one trace buffer, ... As Roman suggested, relayfs ...
    (Linux-Kernel)