[dpdk-dev] two tso related questions

[Helmut Sim]

correct.
In such case, a modified api should not require to set the ip_hdr
total_length field, which is 16 bits.
The HW will assign the correct packet length for each transmitted IP packet
which is l3_len+l4_len+mss (except of the last segment which may be smaller
than mss).

Sim

On Sun, Jan 4, 2015 at 11:57 AM, Alex Markuze <alex at weka.io> wrote:

>
>
> On Sun, Jan 4, 2015 at 10:50 AM, Helmut Sim <simhelmut at gmail.com> wrote:
>
>> Hi Alex and Olivier,
>>
>> Alex, I made the test and the segmentation is not at the IP level (i.e.
>> each packet ip total length indicated the mss length), hence the 16 bits
>> total length limitation is not relevant here.
>>
>
> Oliver thanks for reporting back, this is interesting but doesn't come as
> a surprise as the headers must be correct when on the wire, what I couldn't
> tell you is what happens with the identificayion/Frag off fields.
>
> The IP length limitation comes from the send side network stack,
> theoreticaly Its possible to send a packet of any size as long as your
> network stack doesn't mind sending a packet with a malformed IP header(as
> the length field is not defined).
>   .
> The send side HW recieves a single packet with the ip length of the whole
> packet. Assuming that the ixgbe HW takes the packet len for its TSO
> fragmentation from the TX descriptor rather then from the IP header, it
> should be able to send as much as the HW supports.
>
>
>> I went over the 82599 datasheet and as Olivier mentioned it is a 18 bits
>> field, hence allowing up to 256KB length.
>>
>> Olivier, although tcp window size field is 16 bits the advertised window
>> is typically higher than 64KB using the TCP window scaling option (which is
>> the common usage today).
>>
>> Hence I think that the API should allow at least up to 256KB packet
>> length, while finding a solution to make sure it also support lower lengths
>> for other NICs.
>>
>> Any idea?
>>
>> Sim
>>
>> On Wed, Dec 17, 2014 at 3:02 PM, Olivier MATZ <olivier.matz at 6wind.com>
>> wrote:
>>
>>> Hi Helmut,
>>>
>>> On 12/17/2014 08:17 AM, Helmut Sim wrote:
>>>
>>>> While working on TSO based solution I faced the following two questions:
>>>>>>>>
>>>>>>>> 1.
>>>>>>>> is there a maximum pkt_len to be used with TSO?, e.g. let's say if
>>>>>>>> seg_sz
>>>>>>>> is 1400 can the entire segmented pkt be 256K (higer than 64K) ?,
>>>>>>>> then
>>>>>>>> the
>>>>>>>> driver gets a list of chanined mbufs while the first mbuf is set to
>>>>>>>> TSO
>>>>>>>> offload.
>>>>>>>>
>>>>>>>
>>> I think the limitations depend on:
>>>
>>> - the window size advertised by the peer: your stack should handle this
>>>   and not generate more packets that what the peer can receive
>>>
>>> - the driver: on ixgbe, the maximum payload length is 2^18. I don't know
>>>   if there is a limitation on number of chained descriptors.
>>>
>>> I think we should define a way to know this limitation in the API. Maybe
>>> a comment saying that the TSO length should not be higher than 256KB (or
>>> fix it to 64KB in case future drivers do not support 256KB) is enough.
>>>
>>> Regards,
>>> Olivier
>>>
>>>
>>
>