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

[Joe Touch <[e-mail]>]

So, *given* that we *are* different from UDP and TCP, i.e., we do NOT have the luxury of a fixed-offset location for this checksum:

- why does the offset distance matter, i.e., front vs. end?
- how *MUCH* does the offset alignment matter, keeping in mind:
	- no offset might require 1 byte-swap at some point, but consumes the least space
	- half-word alignment wastes 4 bits on avg.
	- full-word alignment wastes 12 bits (1.5 bytes) on avg

In comms, the typical figure of merit is 1 opcode per bit. So, IMO:

- if we can save 4 bits with 4 or fewer opcodes, it’s a win
- if we can save 12 bits with 12 or fewer opcodes, it’s a win

My assumption is that offload engines or the core processor need to do “non-halfword length” cleanup regardless.

That cleanup should be at most 5 opcodes:
	load
	mask the addend
	add w/carry
	mask the sum (for the 1’s compl wrap)
	add w/carry (for the 1’s compl wrap)
	swap (if not half-word aligned)

That suggests we’re either very close to no real penalty for “no offset” or that we win by using at least half-word offset.

Note: the alignment overhead will also NEED to be zero - and checked that it’s zero, which are additional opcodes needed that are not too far from the cleanup ones above.

i.e., given the similarity of the zero-check and the cleanup, why is it useful to waste these bytes?

Joe

> On Jul 13, 2019, at 11:49 AM, Tom Herbert <[e-mail]> wrote:
> 
> 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
> 
>> 
>