Re: [dpdk-dev] two tso related questions

[Helmut Sim <simhelmut@gmail.com>]

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.
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@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
>
>