James Carlson wrote:
> Kacheong Poon writes:
>> For example, suppose we want to use the TCP MD5 option. I
>> think it will work nicely with MDT. But I don't know if there
>> is (or ever will be?) a hardware out there doing LSO which can
>> fill in the MD5 option value. As another example, MDT can
>> support the ECN nonce in RFC 3168 nicely. I doubt that there
>> is a hardware out there doing LSO that can do ECN nonce.
>
> Yep, and, as I mentioned, IPsec is pretty problematic with LSO, but
> "easy" with MDT.
Do the double-quotes mean that it is really hard, or something different?
Today we have to disable LSO and MDT when we add ESP or AH to the
packet. It is not impossible to make all of the ESP, AH and other IPsec
code have special handling for M_MULTIDATA but that by itself might not
buy the MDT performance improvement. For the MDT DMA/IOMMU benefits to
appear the result of applying ESP needs to result in one contiguous
payload instead of N separate encrypted payloads. Thus this would result
in more overhead just to manage the multiple packets in the M_MULTIDATA.
I'm personally a fan of having a minimal number of instructions in the
data paths and the M_MULTIDATA code doesn't satisfy that - it needs to
manage all the metadata which is extra work compared to a soft LSO
implementation.
So while LSO has some limitations, it is a more tractable way to
amortize DMA/IOMMU overhead than MDT.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
