Re: [tsvwg] Alternative version of the UDP FRAG option

[Tom Herbert <[e-mail]>]

On Sat, Mar 16, 2019 at 12:06 PM Joe Touch <[e-mail]> wrote:
>
>
>
> On Mar 16, 2019, at 11:37 AM, Tom Herbert <[e-mail]> wrote:
>
>
>
> On Sat, Mar 16, 2019, 11:21 AM Joe Touch <[e-mail]> wrote:
>>
>>
>>
>> On Mar 16, 2019, at 9:06 AM, Tom Herbert <[e-mail]> wrote:
>> Hi Mike,
>>
>> Thinking about this, it occurs to me be that the LITE option isn't
>> needed.
>>
>>
>> AFAICT, there is no LITE option the way you have been trying to evolve it.
>>
>> The assumption in the UDP options draft is that a receiver
>> needs the UDP payload to immediately follow the UDP header, but the
>> UDP payload can be anywhere in the surplus area as long as it's
>> aligned to four bytes. A receiver will know how to handle it and
>> deliver the UDP data to the application (e.g. by maintaining a pointer
>> to the data).
>>
>> So that allows a format like:
>>
>> UDP header (Length=8) | Surplus area header | Options | Payload
>>
>>
>> That’s DOA for legacy receivers.
>
>
> Legacy receivers see a UDP datagram with zero payload, just like LITE.
>
>
> I misunderstood payload to also include cases where Len > 8. Fair enough.
>
>
>>
>> It also basically kills zero-copy.
>
>
> Exactly how does it do that?
>
>
> Zero copy UDP would need to I’ve the lite payload after it has already been placed in memory. That’s not true for the current approach (it was a design goal, in fact, to allow it).

Joe,

Zero-copy can be used for both send and receive. A good background
description is in https://lwn.net/Articles/726917/

Sending is the easier of the two. Zero-copy send just needs simple
scatter-gather support. There are two buffers, one contains packets
headers and the other contains the data (e.g. a page from the page
cache). Packet in metadata (e.g. an skbuf) looks like
Header_buffer->data_buffer. The protocol headers are arbitrary (TCP,
UDP, IPv6, encapsulation, ULP headers, etc.). Protocol trailers
complicate this since the metadata now looks like
Header_buffer->data_buffer->trailer_buffer. I'm not sure that is
easily supported with current implementations. Also note, in zero copy
we're not allowed to touch the data memory so the byte swap done in
LITE can't be done in the data buffer.

Receive zero copy works in two modes: mapping receive buffers and
header data split. Mapping receive buffers (i.e. to userspace) allows
zero copy. The application gets pointers to data and extent, but they
also can access the headers and possibly data that from previous
received that wasn't overwritten-- so there are security concerns. The
data is rarely aligned to what is most useful for the application
(like we might want the receive data for a disk block to be page
aligned). Header-data split is intended to solve that problem, however
it requires the network device (NIC) to understand the ULP and locate
the application data (naively spitting out UDP or TCP data like some
early NICs did doesn't help). Programmable devices might be help solve
this problem. For protocol trailers, there is a new convolution since
now the device would need to do header-data-trailer split.

A related mechanism is parsing buffer. Parsing buffers are used in
hardware devices that want to inspect the headers of different layers
in a packet. It's basically a cache that contains the first N bytes of
a packet that can be processed. N is something like 128, 256, or more
recently 512 bytes. If the headers they device is interested in is
beyond the extent of the parsing buffer then the device may take some
undesirable action like dropping the packet or relegating it to a slow
software path. Protocol trailers are likely to be a problem for
devices with parsing buffers that want to inspect the trailers.

Tom

>
> Joe