From: Vlad Yasevich <vyasevic@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, edumazet@google.com
Subject: Re: [PATCH net] net: Correctly set segment mac_len in skb_segment().
Date: Fri, 01 Aug 2014 08:58:56 -0400 [thread overview]
Message-ID: <53DB8F10.8090901@redhat.com> (raw)
In-Reply-To: <20140731.222912.1916841568774711697.davem@davemloft.net>
On 08/01/2014 01:29 AM, David Miller wrote:
> From: Vlad Yasevich <vyasevic@redhat.com>
> Date: Thu, 31 Jul 2014 10:33:06 -0400
>
>> When performing segmentation, the mac_len value is copied right
>> out of the original skb. However, this value is not always set correctly
>> (like when the packet is VLAN-tagged) and we'll end up copying a bad
>> value.
>>
>> One way to demonstrate this is to configure a VM which tags
>> packets internally and turn off VLAN acceleration on the forwarding
>> bridge port. The packets show up corrupt like this:
>> 16:18:24.985548 52:54:00:ab:be:25 > 52:54:00:26:ce:a3, ethertype 802.1Q
>> (0x8100), length 1518: vlan 100, p 0, ethertype 0x05e0,
>> 0x0000: 8cdb 1c7c 8cdb 0064 4006 b59d 0a00 6402 ...|...d@.....d.
>> 0x0010: 0a00 6401 9e0d b441 0a5e 64ec 0330 14fa ..d....A.^d..0..
>> 0x0020: 29e3 01c9 f871 0000 0101 080a 000a e833)....q.........3
>> 0x0030: 000f 8c75 6e65 7470 6572 6600 6e65 7470 ...unetperf.netp
>> 0x0040: 6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
>> 0x0050: 6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
>> 0x0060: 6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp
>> ...
>>
>> This also leads to awful throughput as GSO packets are dropped and
>> cause retransmissions.
>>
>> The solution is to set the mac_len using the values already available
>> in then new skb. We've already adjusted all of the header offset, so we
>> might as well correctly figure out the mac_len using skb_reset_mac_len().
>> After this change, packets are segmented correctly and performance
>> is restored.
>>
>> CC: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>
> Applied, and I'm assuming this is meant to go to -stable too right?
>
yes, please.
Thanks
-vlad
prev parent reply other threads:[~2014-08-01 12:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 14:33 [PATCH net] net: Correctly set segment mac_len in skb_segment() Vlad Yasevich
2014-08-01 5:29 ` David Miller
2014-08-01 12:58 ` Vlad Yasevich [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=53DB8F10.8090901@redhat.com \
--to=vyasevic@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.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.