RE: Bypass qdiscs?

[David Laight <David.Laight@ACULAB.COM>]

From: David Ahern
> Sent: 08 November 2023 17:17
> 
> On 11/8/23 9:50 AM, John Ousterhout wrote:
> > Hi David,
> >
> > Thanks for the suggestion, but if I understand this correctly, this
> > will disable qdiscs for TCP as well as Homa; I suspect I shouldn't do
> > that?
> >
> 
> A means to separate issues - i.e., run Homa tests without qdisc overhead
> or delays. You can worry about how to handle if/when you start
> upstreaming the code.

Isn't the qdisc overhead pretty minimal most of the time anyway?
If I send a RAW_IP (and probably UDP) packet the ethernet MAC
packet setup (etc) is normally done by direct calls from the
process calling sendmsg().

If two threads call sendmsg (on different sockets) at the same
time something has to give somewhere.
To avoid stalling the 2nd thread, the packet gets queued and is
picked up by the first thread before it returns.

To bypass the qdisc wouldn't you need a MAC driver that can
processes multiple transmit setup requests in parallel?
It can be done for a simple memory ring based interface - just
use a lock to grab the required slots in the transmit ring.
Then it doesn't matter which order setups complete in.
But I don't think Linux makes that easy to write.

Transmit flow control will also require queueing (or discard).
If Homa and TCP are sharing a physical network then surely the
TCP traffic can cause flow control issue for both?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)