[EMAIL PROTECTED] wrote: > Subject: Re: Van Jacobson's net channels and real-time > > > On Mon, 24 Apr 2006, Auke Kok wrote: > >> Ingo Oeser wrote: >>> 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. >> >> MSI-X. with MSI you still have only one cpu handling all MSI >> interrupts and that doesn't look any different than ordinary >> interrupts. MSI-X will allow much better interrupt handling across >> several cpu's. >> >> Auke >> - > > Message signaled interrupts are just a kudge to save a trace > on a PC board (read make junk cheaper still). They are not > faster and may even be slower. They will not be the salvation > of any interrupt latency problems. The solutions for > increasing networking speed, where the bit-rate on the wire > gets close to the bit-rate on the bus, is to put more and > more of the networking code inside the network board. The CPU > get interrupted after most things (like network handshakes) > are complete. >
The number of hardware interrupts supported is a bit out of scope. Whatever the capacity is, the key is to have as few meaningless interrupts as possible. In the context of netchannels this would mean that an interrupt should only be fired when there is a sufficient number of packets for the user-mode code to process. Fully offloading the protocol to the hardware is certainly one option, that I also thinks make sense, but the goal of netchannels is to try to optimize performance while keeping TCP processing on host. More hardware offload is distinctly possible and relevant in this context. Statefull offload, such as TSO, are fully relevant. Going directly from the NIC to the channel is also possible (after the channel is set up by the kernel, of course). If the NIC is aware of the channels directly then interrupts can be limited to packets that cross per-channel thresholds configured directly by the ring consumer. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html