Hi Erik
Another important note I think you're missing about MDT,
what appears to be happening below is a transform from Data
to encrypted data. Which simply can mean to MDT you allocate
a buffer for the resultant encrypted packets which will be
the payload part of the MDT message, no need for a header
the driver gets payload buffers with one packet after another
described by the pdesc structure. The driver just sends it using
the MDT path with no interpretation beyond this is an MDT message.
You get the benefit of locking down/syncing only one payload buffer,
the benefit of traversing the stack once and finally all that for a bunch
of packets.
The down side someone has to to the implementation.... oops...
any takers for a prototype???? I have a working MDT for
a 10G adapter??? ;-)
Frank
Erik Nordmark wrote:
> 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]
>
_______________________________________________
networking-discuss mailing list
[email protected]
