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: Tue, 16 Dec 2014 14:24:55 +0200 [thread overview]
Message-ID: <CAF8yGaFO+VXnvh1Er=oWUPrbGqc46fJdCp7Wez3gNgcjLCdqZw@mail.gmail.com> (raw)
In-Reply-To: <CAKfHP0WY8n1tyxw7jbeBU2EgrAziyv+1h+xAuLyQ7Uu9AgiSzw@mail.gmail.com>
Thanks Alex,
So i probably miss something...
what you are saying is correct for IP segmentation where the segmentation
is at the IP level, and all segments are identified according to the
Identification field in the IP header.
However in TCP segmentation the segments are at the TCP level (isn't it?),
where each frame is at a size of
MSS+sizeof(tcp_hdr)+sizeof(ip_hdr)+sizeof(eth_hdr).
Hence, for each of the sent packets, the IP Identification is 0 and the IP
total length is MSS+sizeof(tcp_hdr)+sizeof(ip_hdr).
Please correct me if i am wrong.
thanks.
On Tue, Dec 16, 2014 at 11:10 AM, Alex Markuze <alex@weka.io> wrote:
>
>
>
> On Mon, Dec 15, 2014 at 10:20 PM, Helmut Sim <simhelmut@gmail.com> wrote:
>>
>> Hi,
>>
>> 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.
>>
>
> TSO segments a TCP packet into mtu sied bits. The TCP/IP protocols are
> limited to 64K due to the length fields being 16bit wide. You can't build a
> valid packet longer then 64K regardless of the NIC.
>
>
>> 2.
>> I wonder, Is there a specific reason why TSO is supported only for IXGBE
>> and not for IGB ? the 82576 NIC supports TSO though.
>> Is it due to a kind of tecnical barrier or is it because of priorities?
>>
>> It will be great if someone from the forum could address this.
>>
>> Thanks,
>> Sim
>>
>
next prev parent reply other threads:[~2014-12-16 12:24 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 [this message]
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
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='CAF8yGaFO+VXnvh1Er=oWUPrbGqc46fJdCp7Wez3gNgcjLCdqZw@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).