Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Sat, Jul 13, 2019 at 11:26 AM Derek Fawcus
<[e-mail]> wrote:
>
> On Thu, Jul 11, 2019 at 07:07:39PM -0700, Joe Touch wrote:
> >
> > Not sure I follow here - so there are only a few variants that seem viable:
> >
> > 1.- at the front of the surplus space
> > 2.- at the front of the surplus space after alignment NOPs
> > 3.- at the end of the surplus space
> > 4.- at the end of the surplus space with alignment
> >
> > AFAICT, there’s no real help in requiring OCS be aligned (it can be designed to tolerate any alignment), which means we don’t need #2 or #4.
>
> Agree.  I see no need for alignment.
>
> > So what’s preferable here? #1 or #3?
>
> Not sure.
>
> I'd be inclined to pick 1, but could be convinced that 3 is better.
>
> If we're talking of h/w offload engines [*], I imagine that they could
> handle 'write to 2 bytes before end of packet' more easily than
> 'write to start of surplus'.

Derek,

It's the other way around because offload engines are primarily built
to deal TCP and UDP checksums which have always been in headers
towards beginning of the packet. Similarly, HW can optimize for
checksum being aligned since UDP and TCP checksums have always been
aligned.

>
> DF
>
> [*] How many do this with random logic?  My current impression is that
>     most such devices are programmable cores, e.g. ARM or MIPS cores.

Actually no, checksum offload is in ASICs and maybe some FPGA. NICs
are getting cores now in so called Smart-NICs, but those are more
likely to be applied towards more complex protocol parsing and
processing. CPUs in the NIC won't fundamentally improve how checksum
offload, the solutions for that are well established and understood.

If you're interested, we will be presenting a technlogy deep dive
@IETF105 that will cover a lot of topics around NIC technology:
https://datatracker.ietf.org/meeting/105/materials/agenda-105-tdd-01

Tom

>