Re: Impact of hardware offloads on network stack performance

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Thanks for the pointer.

I doubt you will see similar gains (92%) in UDP because there is going to
be a lot of kernel context switches, one for each packet vis sendmsg.
Copying is probably not the dominating factor here.

I do wish there was an easier way to use the netmap interface without
kernel patches and without taking over the entire network card, e.g. by
binding netmap to a single UDP port.

https://www.unix.com/man-page/freebsd/4/netmap/

Mikkel

On 10 May 2018 at 14.50.13, craigt ([e-mail]) wrote:

Has anyone experimented with the zerocopy socket interfaces for exactly
this use case?
  https://netdevconf.org/2.1/papers/netdev.pdf

It would seem that is a more natural fit to the assertions made by several
of the authors surrounding packetisation.
I'm unaware if Windows/BSD have similar interfaces/implementations.

c


On 30 April 2018 at 21:37, Roberto Peon <[e-mail]> wrote:

> QUIC (mostly) doesn’t do that (rexmit a packet verbatim)—you’d need a new
> packet# for the rexmitted packet.
>
> -=R
>
>
>
> *From:* QUIC <[e-mail]> on behalf of Watson Ladd <
> [e-mail]>
> *Date:* Monday, April 23, 2018 at 1:56 PM
> *To:* Mike Bishop <[e-mail]>
> *Cc:* Praveen Balasubramanian <[e-mail]>, "Lubashev, Igor" <
> [e-mail]>, Ian Swett <ianswett=[e-mail]>,
> Mikkel Fahnøe Jørgensen <[e-mail]>, IETF QUIC WG <[e-mail]>,
> "Deval, Manasi" <[e-mail]>
> *Subject:* Re: Impact of hardware offloads on network stack performance
>
>
>
>
>
>
>
> On Mon, Apr 23, 2018 at 1:06 PM, Mike Bishop <[e-mail]> wrote:
>
> I agree – the point of offloading the crypto is not only to spare that
> cost on the CPU, though that can be useful, it’s to enable further offloads
> that can’t be done on the encrypted packet.
>
>
>
> LRO that could simply group packets by CID and deliver a single batch of
> packets from a single CID in a single invocation seems like a great first
> step, and doesn’t even require crypto offload.  Once you have crypto
> offload, of course those packets per CID could be delivered already
> decrypted.  I’d want to see data on whether there’s value in making the
> received data look like one huge packet when there’s not a single
> bytestream, but that’s not something we need to specify here.
>
>
>
> LSO is more interesting, and the challenge there is that the transport
> stack still needs to know what data was in which packet so that it can do
> loss recovery properly.  QUIC explicitly disallows fragmentation of the UDP
> datagram, for the “painful and potentially non-deterministic” reasons you
> referenced.
>
>
>
> Forgive my complete ignorance, but doesn't it just need to know what
> packet it sent?
>
> More explicitly the sender would maintain a queue of sendable packets, and
> mark which have been sent. Acknowledged packets are removed from the queue.
> In event of loss, they simply retransmit the same packet. It's up to higher
> layers to pick the right size of packet and take data from the individual
> QUIC streams. If you wanted to expose the stream structure, that sounds a
> lot more complicated.
>
>
> Sincerely,
>
> Watson
>
>
>
>
>