Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy

[Patrick McHardy <kaber@trash.net>]

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.