From: Or Gerlitz <ogerlitz@voltaire•com>
To: Jan-Bernd Themann <THEMANN@de•ibm.com>,
Eli Cohen <eli@dev•mellanox.co.il>
Cc: netdev@vger•kernel.org, Roland Dreier <rdreier@cisco•com>,
Vladimir Sokolovsky <vlad@mellanox•co.il>,
OpenFabrics General <general@lists•openfabrics.org>
Subject: Re: [ofa-general] [PATCH] net/inet_lro: remove setting skb->ip_summed when not LRO-able
Date: Wed, 25 Jun 2008 14:47:25 +0300 [thread overview]
Message-ID: <4862304D.2050306@voltaire.com> (raw)
In-Reply-To: <OFEBCC17DD.4CE7F0B2-ONC1257473.003ED3DA-C1257473.003EE40F@de.ibm.com>
Jan-Bernd Themann wrote:
> no, what I meant is that it is only not needed at that particular
> place as the packet is not handled by LRO. Without this line the
> driver can set an individual value for each SKB that is not
> aggregated if wished. For example when the packet is not a valid IP
> packet. However, removing all ip_summed fields impacts the fragment
> lro mode. There we have to set some value for not aggregated packets.
> The SKBs are generated within the LRO engine. If desired (and if there
> is HW that wants to use that) we can pass that value for each provided
> fragment. This would add one additional paramter to the already 8
> parameters of __lro_proc_segment. That is of course possible.
OK, understood, both points.
Eli, lets add to this patch a comment in inet_lro.h saying that the
value of lro_mgr->ip_summed is ignored by the core lro code for drivers
that use the non fragmented mode. Also for the ipoib patch, lets not set
this value.
> I think that for valid TCP/IP packets this value should always be the
> same as the hardware either support the set ip_summed_aggr value for
> TCP/IPv4 packets, or not. Maybe that assumption is not right, but so
> far I haven't seen any hardware that behaves in a different way.
Yes, for TCP/IPv4 you seem to be right and here the problem was in the
lro patch to ipoib which set this value blindly regardless of the HW
capabilities, I asked Vlad to change this in the next version of the
patch. As for other types of traffic, I was thinking that allowing the
driver to set it per packet makes a better isolation between the core
lro code to the driver, but this is not major issue.
> yes, that is possible. An increased delay is the prise of LRO :-)
>
Is there some pointer you might be able to provide on LRO benchmark for
small packets and/or mixed small/large packet streams?
Or.
next prev parent reply other threads:[~2008-06-25 11:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1214318386.23583.37.camel@mtls03>
2008-06-25 9:26 ` [ofa-general] [PATCH] net/inet_lro: remove setting skb->ip_summed when not LRO-able Or Gerlitz
2008-06-25 11:28 ` Jan-Bernd Themann
2008-06-25 11:47 ` Or Gerlitz [this message]
2008-06-25 12:10 ` Jan-Bernd Themann
2008-06-25 12:15 ` Jan-Bernd Themann
2008-06-25 12:30 ` Eli Cohen
2008-06-25 13:01 ` Or Gerlitz
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=4862304D.2050306@voltaire.com \
--to=ogerlitz@voltaire$(echo .)com \
--cc=THEMANN@de$(echo .)ibm.com \
--cc=eli@dev$(echo .)mellanox.co.il \
--cc=general@lists$(echo .)openfabrics.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rdreier@cisco$(echo .)com \
--cc=vlad@mellanox$(echo .)co.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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