[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D764030.8020202@trash.net>
Date: Tue, 08 Mar 2011 15:41:52 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Daniel Lezcano <daniel.lezcano@...e.fr>
CC: Eric Dumazet <eric.dumazet@...il.com>,
Andrian Nord <nightnord@...il.com>,
lxc-users@...ts.sourceforge.net,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
Am 02.03.2011 19:33, schrieb Daniel Lezcano:
> On 03/02/2011 07:03 PM, Patrick McHardy wrote:
>> 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.
>
> Ok, I understand. thanks for the clarification.
>
>>> 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.
>
> One last question. In the case of broadcast packets with maclvan in
> bridge mode.
> We will have the packets going through each macvlan port and also to the
> lower-device, right ?
> For the latter, don't we have a problem if the packet is flagged
> CHECKSUM_UNNECESSARY ?
>
> Shouldn't we restore the ip_summed field before sending through
> dev_queue_xmit ?
Yes, that seems correct in order to have dev_hard_start_xmit() complete
the checksum if necessary.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists