From: Steffen Klassert <steffen.klassert@secunet.com>
To: Ansis Atteka <ansisatteka@gmail.com>
Cc: Ansis Atteka <aatteka@ovn.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net] xfrm: calculate L4 checksums also for GSO case before encrypting packets
Date: Thu, 27 Apr 2017 11:04:04 +0200 [thread overview]
Message-ID: <20170427090404.GY2649@secunet.com> (raw)
In-Reply-To: <CAMQa7Bgn58eWhwH-tOJcoNoF7ATs5yBpAyu1rR4JN5=8pBdaMA@mail.gmail.com>
On Fri, Apr 21, 2017 at 02:45:17PM -0700, Ansis Atteka wrote:
>
> I removed Geneve tunneling from equation and tried to run a simple
> iperf underlay UDP test while IPsec was still enabled to observe
> issues with the udp4_ufo_fragment() case.
>
> Unfortunately, as can be seen from kernel tracer output below, I was
> unable to come up with a test case where udp4_ufo_fragment function
> would ever be invoked while IPsec is enabled:
>
> admin1@ubuntu1:~/xfrm_test/net$ ifconfig em2.4001 | grep "inet addr"
> inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
> admin1@ubuntu1:~/xfrm_test/net$ ethtool -k em2.4001 | grep
> udp-fragmentation-offload
> udp-fragmentation-offload: on
> admin1@ubuntu1:~/xfrm_test/net$ sudo trace-cmd record -p
> function_graph -c -F iperf -c 192.168.1.2 -u -l20000
> admin1@ubuntu1:~/xfrm_test/net$ trace-cmd report | grep udp4
> admin1@ubuntu1:~/xfrm_test/net$
>
>
> Nevertheless, after disabling IPsec and leaving everything else the
> same, I start to see that udp4_ufo_fragment() gets invoked:
>
> admin1@ubuntu1:~/xfrm_test/net$ trace-cmd report | grep udp4
> iperf-25466 [004] 242431.203307: funcgraph_entry:
> 0.113 us | udp4_hwcsum();
> iperf-25466 [004] 242431.203360: funcgraph_entry:
> |
> udp4_ufo_fragment() {
> iperf-25466 [004] 242431.508436: funcgraph_entry:
> 0.080 us | udp4_hwcsum();
> iperf-25466 [004] 242431.508542: funcgraph_entry:
> |
> udp4_ufo_fragment() {
>
>
> However, non-IPsec case really does not have this ESP packet
> corruption problem, because then the packets are in plain and can
> utilize checksum offloads. Do we really have a problem there for
> IPsec?
Probably not, at least locally generated packets don't do
ufo if they have an IPsec route. So it seems to be ok to
leave udp4_ufo_fragment as it is.
prev parent reply other threads:[~2017-04-27 9:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 18:42 [PATCH net] xfrm: calculate L4 checksums also for GSO case before encrypting packets Ansis Atteka
2017-04-11 7:07 ` Steffen Klassert
[not found] ` <CAMQa7Biajree5Kc1fOWQN42R1UDDGp7ZevZZRtUMZOKDWTk-Vw@mail.gmail.com>
2017-04-14 2:54 ` Ansis Atteka
2017-04-18 9:09 ` Steffen Klassert
2017-04-19 2:10 ` Ansis Atteka
2017-04-20 9:47 ` Steffen Klassert
2017-04-21 21:45 ` Ansis Atteka
2017-04-27 9:04 ` Steffen Klassert [this message]
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=20170427090404.GY2649@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=aatteka@ovn.org \
--cc=ansisatteka@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.