netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Andrian Nord <nightnord@gmail.com>,
	lxc-users@lists.sourceforge.net,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
Date: Wed, 02 Mar 2011 19:03:50 +0100	[thread overview]
Message-ID: <4D6E8686.3000109@trash.net> (raw)
In-Reply-To: <4D6E6A55.6000607@free.fr>

Am 02.03.2011 17:03, schrieb Daniel Lezcano:
> On 03/02/2011 12:03 PM, Patrick McHardy wrote:
>> Am 01.03.2011 21:04, schrieb Daniel Lezcano:
>>> On 03/01/2011 05:51 PM, Patrick McHardy wrote:
>>>>> Patrick, do you have any suggestions to fix this ?
>>>> Since the frames are only looped back locally, I suppose the easiest
>>>> fix would be to mark them with CHECKSUM_UNNECESSARY. Alternatively
>>>> we need to complete the checksum manually, similar to what
>>>> dev_hard_start_xmit() does.
>>> That sounds very simple to fix, maybe too much simple :)
>>>
>>> I did the following change:
>>>
>>> --- linux-next.orig/drivers/net/macvlan.c
>>> +++ linux-next/drivers/net/macvlan.c
>>> @@ -222,6 +222,7 @@ static int macvlan_queue_xmit(struct sk_
>>>
>>>          if (vlan->mode == MACVLAN_MODE_BRIDGE) {
>>>                  const struct ethhdr *eth = (void *)skb->data;
>>> +               skb->ip_summed = CHECKSUM_UNNECESSARY;
>>>
>>>                  /* send to other bridge ports directly */
>>>                  if (is_multicast_ether_addr(eth->h_dest)) {
>>>
>>>
>>> and that fixed the problem. Do you think it is acceptable ?
>> The only problem I see is if the packets are bridged to a
>> different networking device (or redirected using the mirred
>> action), in this case the checksum will not be completed.
>> This would be a very strange setup though and probably wouldn't
>> be using dummy as lower device, so I'm not sure we have to
>> worry about this case.
> 
> I am not sure to get it, do you say the patch is correct ?

Its correct with a short-coming that doesn't seem to matter.

> If my understanding is correct, the packet will be flagged
> CHECKSUM_UNNECESSARY only for the macvlan devices, right ?

Only for packets bridged between macvlan devices. A setup like
the following would cause problems:

                        br0
                         |
                   .----------.
                   |          |
macvlan0	macvlan1    eth0
   |               |
    -------.-------
	 dummy0

In this case packets sent from macvlan0 will show up on
eth0 with incorrect setups. However this setup doesn't
seem realistic to me, you would simply use eth0 instead
of dummy0.

> By the way, this problem occurs for any lower device with offloading
> capabilities with a macvlan port in bridge mode.

True. This doesn't affect outgoing packets since their checksum
will be completed in dev_hard_start_xmit(), but it affects
packets bridged between macvlans.

As I said, the full solution would be to complete the checksum
for CHECKSUM_PARTIAL packets when bridging between macvlans.

  reply	other threads:[~2011-03-02 18:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110221150710.GA5651@nord.niifaq.ru>
     [not found] ` <4D6282DB.2080204@free.fr>
     [not found]   ` <20110221153421.GA6602@nord.niifaq.ru>
2011-02-21 16:07     ` [Lxc-users] Huge ammount of invalid checksum packets on macvlan Daniel Lezcano
     [not found]       ` <4D628DC3.9000400-GANU6spQydw@public.gmane.org>
2011-02-21 17:39         ` Andrian Nord
2011-02-23 17:13       ` [Lxc-users] Bad checksums and lost packets with macvlan on dummy Andrian Nord
2011-02-24 10:20         ` Daniel Lezcano
2011-02-26 20:38           ` Andrian Nord
2011-02-27 15:14         ` Daniel Lezcano
2011-02-27 19:50           ` Eric Dumazet
2011-02-27 20:35             ` Daniel Lezcano
2011-02-28  7:45               ` [Lxc-users] " Eric Dumazet
2011-03-01 13:29                 ` Daniel Lezcano
2011-03-01 16:51                   ` Patrick McHardy
2011-03-01 20:04                     ` Daniel Lezcano
2011-03-02 11:03                       ` Patrick McHardy
2011-03-02 16:03                         ` Daniel Lezcano
2011-03-02 18:03                           ` Patrick McHardy [this message]
2011-03-02 18:33                             ` Daniel Lezcano
2011-03-03 14:30                               ` Changli Gao
2011-03-08 14:41                               ` Patrick McHardy
     [not found]                                 ` <4D764030.8020202-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2011-03-12 21:59                                   ` Daniel Lezcano
2011-03-12 22:07                                     ` [Lxc-users] " Daniel Lezcano

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=4D6E8686.3000109@trash.net \
    --to=kaber@trash.net \
    --cc=daniel.lezcano@free.fr \
    --cc=eric.dumazet@gmail.com \
    --cc=lxc-users@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=nightnord@gmail.com \
    /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).