From: "Raúl Hernández" <rauhersu@gmail.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Cc: netdev@vger.kernel.org
Subject: Re: high rate injection and fragmentation
Date: Mon, 9 Feb 2009 18:18:50 +0100 [thread overview]
Message-ID: <3f847c820902090918j4da4b94o3eee35415f088afb@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0902091806510.31742@wrl-59.cs.helsinki.fi>
Hi Ilpo,
Thanks for your answer, I did not know about that feature. Looking at
my settings:
# ethtool -k eth2
...
tcp segmentation offload: on
I think ethereal hooks up before reaching the TCP offload which is
handled by the NIC.
Best regards,
Raul
On Mon, Feb 9, 2009 at 5:09 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> On Mon, 9 Feb 2009, Raúl Hernández wrote:
>
>> I am trying to understand the behavior of the IP stack regarding
>> fragmentation when injecting at high speed ratio : so far I am seeing
>> that TCP starts multiplexing the application level protocol (in my
>> case, diameter: previously 1 diameter message = 1 TCP message, when
>> the rate increases, multiple diameter messages are coalesced in one
>> TCP messages - similar to a Nagle control -).
>>
>> At that very moment is when we start finding issues regarding packet
>> length checking with ethereal: frames start growing due the multiplex
>> above and ethereal shows captured packets >3000 bytes ! (IP total
>> lenght makes sense as well according to that figure). The thing is
>> that I am working under ethernet law (1500 bytes) and I have checked
>> through iproute this is the MTU set for the link (neither
>> DONT_FRAGMENT ip options for the socket regarding nor MTU
>> modifications have been introduced) so my understanding is that no
>> packet > 1500 bytes should be allowed with my configuration (would
>> need fragmentation).
>>
>> Checking the IP header with ethereal, "dont fragment" is set and
>> "fragment offset"=0. IOW, It seems that IP is not fragmenting the
>> packet although > MTU which I am not able to understand.
>>
>> Any idea why Linux tries to work with MTU > 1500 bytes when not
>> configured explicitly to do so (may I have missed more
>> options/checkings) ? Hope not to be cheated by Ethereal ...
>
> I suppose you refer here to what GSO is doing though the explanation
> is so fuzzy that I lost track of it in the middle. ...You needs
> ethtool to configure it.
>
> --
> i.
--
Los viajes son en la juventud una parte de educación y, en la vejez,
una parte de experiencia -- Francis Bacon
next prev parent reply other threads:[~2009-02-09 17:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-09 15:20 high rate injection and fragmentation Raúl Hernández
2009-02-09 16:09 ` Ilpo Järvinen
2009-02-09 17:18 ` Raúl Hernández [this message]
2009-02-09 23:10 ` David Miller
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=3f847c820902090918j4da4b94o3eee35415f088afb@mail.gmail.com \
--to=rauhersu@gmail.com \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=netdev@vger.kernel.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).