Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Tom Herbert <[e-mail]>]

On Thu, Mar 21, 2024 at 9:11 AM Robinson, Herbie
<[e-mail]> wrote:
>
> It’s definitely a problem for the 10G x7-- NICs that Intel is currently selling (I’ve been working on porting the driver).  It would require coordinated firmware and driver updates because the driver to firmware interface isn’t defined for this case.  I don’t want to publicly say why, but I would hazard a guess there is no way that would ever happen.
>
>
>
> And from a practical standpoint, one needs NICs to scan packets and route different streams to different receive queues -- it’s still not possible for a single core to handle a 10G data stream.  Especially if you are also breaking checksum offload, etc.

Herbie,

This only would break protocol specific checksum offload where the
device needs to parse the packet to set the checksum. It would not
break protocol agnostic checksum offload. We've been pleading with NIC
vendors for more than ten years to support protocol agnostic checksum
offload precisely because protocol specific checksum offload is so
fragile and so narrow in use case. Unfortunately, some vendors have
refused to listen, and I don't believe we shouldn't move the Internet
forward just to accommodate them.

TSO will similarly work if the device supports a generic mechanism.

To include port numbers in RSS hash would require some changes. An
unmodified NIC would probably just hash over IP addresses and maybe
protocol numbers.

To round it out the list of basic NIC offload, LRO would also require
some changes. But LRO never really was deployed much anyway because it
really wants to be programmed. Fully programmable NICs may change this
story.

Tom


>
>
>
> As for NICs, I don't think that is much of a problem any more. We now
> expect them to be programmable to easily support new protocols. So
> skipping over some new EH to find port numbers isn't much of an issue
> (actually, it's the same code they would use with IPv6 so it's just a
> matter of enabling the protocol numbers for new EH).
>