On Tue, Jul 12, 2022 at 7:31 AM Robinson, Herbie < herbie.robin...@stratus.com> wrote:
> Fred Templin Wrote: > > > Tom: > > >>The algorithm isn't the problem, it's supporting new protocols and > multiple > > >>checksums in a packet in hardware. > > > > >But Tom, how hard can this be? Instead of running the Internet checksum 1 > time > > >over N octets of data simply run it M times over N/M octet chunks of the > data in > > >succession but still in a single pass. You spoke before of NICs adapting > to support > > >TCP jumbograms – if they can do that, why not a very straightforward > application > > >of Internet checksum? I haven’t looked at this in a long while, but isn’t > this also > > >similar to what UDP-lite did? > > > > The various hardware adapters that I am familiar with (most of Intel’s > high end line) use a fixed sized ring buffer with a fixed sized slot for > each packet received. They are already restricting the use of all features > at the same time because they don’t have enough bits in the per packet > slot. They certainly have no way to deal with reporting success or failure > of an unbounded number of checksum computations in a fixed sized slot. > Herbie, Generating multiple checksum is required for TSO and some devices implement a generic mechanism that might be extended to work with IP parcels. On the RX side, efficiently handling multiple checksums in a single packet that cover large non-overlapping portions of the packet is difficult. This can be solved if the IP parcels header has a checksum covering the whole packet so that the receiving host doesn't have to verify the checksum of each segment. But, you'd still want the checksum in each segment in that case. Tom
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
