DPDK patches and discussions
 help / color / mirror / Atom feed
From: Helmut Sim <simhelmut@gmail.com>
To: Alex Markuze <alex@weka.io>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] two tso related questions
Date: Sun, 4 Jan 2015 12:13:34 +0200	[thread overview]
Message-ID: <CAF8yGaHydSrgF7aWcXGy=AbmmpMKVmrjuqDtazFoeh6TRW+y0w@mail.gmail.com> (raw)
In-Reply-To: <CAKfHP0W3jLTQeTvyKtUgKd0sVVDo1SA5coY=YgvqQpr6BDfNEA@mail.gmail.com>

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@weka.io> wrote:

>
>
> On Sun, Jan 4, 2015 at 10:50 AM, Helmut Sim <simhelmut@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@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
>>>
>>>
>>
>

  reply	other threads:[~2015-01-04 10:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15 20:20 Helmut Sim
2014-12-16  9:10 ` Alex Markuze
2014-12-16 12:24   ` Helmut Sim
2014-12-16 14:04     ` Alex Markuze
2014-12-17  7:17       ` Helmut Sim
2014-12-17 13:02         ` Olivier MATZ
2015-01-04  8:50           ` Helmut Sim
2015-01-04  9:57             ` Alex Markuze
2015-01-04 10:13               ` Helmut Sim [this message]
2015-01-05  8:53                 ` Olivier MATZ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF8yGaHydSrgF7aWcXGy=AbmmpMKVmrjuqDtazFoeh6TRW+y0w@mail.gmail.com' \
    --to=simhelmut@gmail.com \
    --cc=alex@weka.io \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).