Re: [Lxc-users] Huge ammount of invalid checksum packets on macvlan

Re: [Lxc-users] Huge ammount of invalid checksum packets on macvlan

[Daniel Lezcano]

On 02/21/2011 04:34 PM, Andrian Nord wrote:
> Greetings, Daniel.
>
> On Mon, Feb 21, 2011 at 04:20:59PM +0100, Daniel Lezcano wrote:
>
> 2.6.37 kernel with gentoo linux patches (doesn't affect any low-system
> stuff, AFAIK).
> lxc-0.7.2 is used.
>
> Reproducable on two different machines.
> I'm using tcpdump -vvv for bad checksum detection. This also affects
> traffic from container to hardware node (as it's using macvlan to
> communicate with containers by itself).
>
> Also, I've got same problem on UDP packets coming from lan on other
> server and it was worked around by disabeling tx and rx checksum offload
> via ethtool. But dummy devices doesn't allow this.

I am not sure it is a bug. If we go outside of the container context and 
we do the following:

ssh 127.0.0.1
tcpdump -vvv -i lo

We will get the same errors AFAICS.

There is also in the man page the following option:

-K Don't attempt to verify IP, TCP, or UDP checksums. This is useful for 
inter‐
faces that perform some or all of those checksum calculation in 
hardware; other‐
wise, all outgoing TCP checksums will be flagged as bad.

IMO, the checksum is not needed for the virtual macvlan devices, hence 
the checksum is not computed and the checksum tcp packet is not filled. 
As the skb's are flagged as 'checksum not necessary' the packets are not 
dropped by the kernel and are delivered to the network stack. tcpdump 
intercept the raw packet and analyse the header. It will see a bad value 
as this one is a default value.

I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong 
or incomplete.

Thanks
-- Daniel

Re: Huge ammount of invalid checksum packets on macvlan

[Andrian Nord]

[-- Attachment #1.1: Type: text/plain, Size: 2419 bytes --]

On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
> IMO, the checksum is not needed for the virtual macvlan devices, hence 
Well, maybe then I've made a horrible mistake of asking the wrong
question. It's not a bad checksums that are wondering me, but very poor
network traffic performance: I'm getting about ~25kbps of
/dev/zero-to-/dev/null copy via netcat between hosts and mysql queries
from container other than mysql's are horribly laggy.

Strangely enough - while there is such bug on both systems, they are
behaving differently.

First system (router):
   eth1          eth0       dummy0
|----|------------|-----------|-----|   macvlans        |------------|
|  macvlan "lan"  |           |-------------------------| containers |
|   /  \          |           |     |                   | -----------|
|--|---|----------|-----------|-----|                    
   |   |          |           | macvlan                   
   |   |     |----------------|------|
  ---  |     |  eth0  eth1   eth2    | Router-container
  LAN  |     |         |             |
  ---  \---------------/             |
             |-----------------------|


And bug appears much less when copying from container to container, or
from container to HN (but still noticeable, especially in mysql queries),
but it's seen very well when copying from LAN to container. netcat copy
transfer rate shows enormous ~300 Mbps.
/proc/net/dev show many transfer errors but 0 receive errors.

Second system (server):
   eth0         eth1       dummy0
|----------------------------|---------------|
|             no carrier     |-macvlan "lxc" |
|----------------------------|---------------|
                             |
		|---------------------------|
		|        containers         |
		|---------------------------|

We can't link macvlans on eth1, as it has no carrier and macvlans are
not working in this case. Here bug is seen very well, even in
transferring packets from container to container (netcat copy transfer
rate is ~40kbps on this system).
/proc/net/dev show may errors in both directions.

First system is slightly more powerful, but difference in
between-container performance is just too big. Also, tcpdump on both
system reports kernel-dropped packets in great amount.

P.S. netcat copy is:
lxc1) nc6 -l -p 12345 > /dev/null
lxc2) dd if=/dev/zero | nc6 lxc1 12345

[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 387 bytes --]

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

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

[Andrian Nord]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong 
> or incomplete.

I'm confirming, that this happens only when macvlan's are onto dummy net
device. In case of some physical interface under macvlan there is no lost
packages and no broken checksums.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Daniel Lezcano]

On 02/23/2011 06:13 PM, Andrian Nord wrote:
> On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
>> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
>> or incomplete.
> I'm confirming, that this happens only when macvlan's are onto dummy net
> device. In case of some physical interface under macvlan there is no lost
> packages and no broken checksums.
Hmm, that's interesting ...

I saw you were using the command 'nc6', do you use netcat with ipv6 ?

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

[Andrian Nord]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On Thu, Feb 24, 2011 at 11:20:09AM +0100, Daniel Lezcano wrote:
> I saw you were using the command 'nc6', do you use netcat with ipv6 ?

Well, yes and no. I've tried both ipv4 and ipv6 and my notebook has no
ipv6 address assigned, so most terrible connection was though ipv4 =).

At another server there is no ipv6 at all.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Daniel Lezcano]

On 02/23/2011 06:13 PM, Andrian Nord wrote:
> On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
>> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
>> or incomplete.
> I'm confirming, that this happens only when macvlan's are onto dummy net
> device. In case of some physical interface under macvlan there is no lost
> packages and no broken checksums.

I did some tests with a 2.6.35 kernel version and it seems the checksum 
errors do not appear.
I noticed there are some changes in the dummy setup function:

   dev->features   |= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
   dev->features   |= NETIF_F_NO_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;


May be that was introduced by commit:

commit 6d81f41c58c69ddde497e9e640ba5805aa26e78c
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Mon Sep 27 20:50:33 2010 +0000

     dummy: percpu stats and lockless xmit

     Converts dummy network device driver to :

     - percpu stats

     - 64bit stats

     - lockless xmit (NETIF_F_LLTX)

     - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
     NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)

     Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>


Eric,

Andrian is observing, with a couple of macvlan (in bridge mode) on top 
of a dummy interface, a lot of checksums error and packets drop.
Each macvlan is in a different network namespace and the dummy interface 
is in the init_net.

Any ideas ?

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

[Eric Dumazet]

Le dimanche 27 février 2011 à 16:14 +0100, Daniel Lezcano a écrit :
> On 02/23/2011 06:13 PM, Andrian Nord wrote:
> > On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
> >> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
> >> or incomplete.
> > I'm confirming, that this happens only when macvlan's are onto dummy net
> > device. In case of some physical interface under macvlan there is no lost
> > packages and no broken checksums.
> 
> I did some tests with a 2.6.35 kernel version and it seems the checksum 
> errors do not appear.
> I noticed there are some changes in the dummy setup function:
> 
>    dev->features   |= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
>    dev->features   |= NETIF_F_NO_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;
> 
> 
> May be that was introduced by commit:
> 
> commit 6d81f41c58c69ddde497e9e640ba5805aa26e78c
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date:   Mon Sep 27 20:50:33 2010 +0000
> 
>      dummy: percpu stats and lockless xmit
> 
>      Converts dummy network device driver to :
> 
>      - percpu stats
> 
>      - 64bit stats
> 
>      - lockless xmit (NETIF_F_LLTX)
> 
>      - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
>      NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
> 
>      Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>      Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> 
> Eric,
> 
> Andrian is observing, with a couple of macvlan (in bridge mode) on top 
> of a dummy interface, a lot of checksums error and packets drop.
> Each macvlan is in a different network namespace and the dummy interface 
> is in the init_net.
> 
> Any ideas ?

Not sure I understand... I thought dummy was dropping all frames
anyway ?

static netdev_tx_t dummy_xmit(struct sk_buff *skb, struct net_device *dev)
{
        struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);

        u64_stats_update_begin(&dstats->syncp);
        dstats->tx_packets++;
        dstats->tx_bytes += skb->len;
        u64_stats_update_end(&dstats->syncp);

        dev_kfree_skb(skb);
        return NETDEV_TX_OK;
}


Maybe you could describe the setup ?

Re: Bad checksums and lost packets with macvlan on dummy

[Daniel Lezcano]

On 02/27/2011 08:50 PM, Eric Dumazet wrote:
> Le dimanche 27 février 2011 à 16:14 +0100, Daniel Lezcano a écrit :
>> On 02/23/2011 06:13 PM, Andrian Nord wrote:
>>> On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
>>>> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
>>>> or incomplete.
>>> I'm confirming, that this happens only when macvlan's are onto dummy net
>>> device. In case of some physical interface under macvlan there is no lost
>>> packages and no broken checksums.
>> I did some tests with a 2.6.35 kernel version and it seems the checksum
>> errors do not appear.
>> I noticed there are some changes in the dummy setup function:
>>
>>     dev->features   |= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
>>     dev->features   |= NETIF_F_NO_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;
>>
>>
>> May be that was introduced by commit:
>>
>> commit 6d81f41c58c69ddde497e9e640ba5805aa26e78c
>> Author: Eric Dumazet<eric.dumazet@gmail.com>
>> Date:   Mon Sep 27 20:50:33 2010 +0000
>>
>>       dummy: percpu stats and lockless xmit
>>
>>       Converts dummy network device driver to :
>>
>>       - percpu stats
>>
>>       - 64bit stats
>>
>>       - lockless xmit (NETIF_F_LLTX)
>>
>>       - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
>>       NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
>>
>>       Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>>       Signed-off-by: David S. Miller<davem@davemloft.net>
>>
>>
>> Eric,
>>
>> Andrian is observing, with a couple of macvlan (in bridge mode) on top
>> of a dummy interface, a lot of checksums error and packets drop.
>> Each macvlan is in a different network namespace and the dummy interface
>> is in the init_net.
>>
>> Any ideas ?
> Not sure I understand... I thought dummy was dropping all frames
> anyway ?
>
> static netdev_tx_t dummy_xmit(struct sk_buff *skb, struct net_device *dev)
> {
>          struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
>
>          u64_stats_update_begin(&dstats->syncp);
>          dstats->tx_packets++;
>          dstats->tx_bytes += skb->len;
>          u64_stats_update_end(&dstats->syncp);
>
>          dev_kfree_skb(skb);
>          return NETDEV_TX_OK;
> }
>
>
> Maybe you could describe the setup ?

Yes, it is very simple.

There are two network namespaces.

macvlan1 is in network namespace 1
macvlan2 is in network namespace 2

Both are in "bridge" mode, so they can communicate together.
The lower device is dummy0 in the init network namespace.

IMO the problem is coming from the macvlan driver:

dev->features           = lowerdev->features & MACVLAN_FEATURES

As dummy0 has the offloading capabilities set on, the macvlan driver 
inherit these features.

In the normal case, dummy0 is supposed to drop the packets. But with 
macvlan these packets are broadcasted to the other macvlan ports, so no 
checksum is computed when the packets are transmitted between macvlan1 
and macvlan2.

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users

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

[Eric Dumazet]

Le dimanche 27 février 2011 à 21:35 +0100, Daniel Lezcano a écrit :
> On 02/27/2011 08:50 PM, Eric Dumazet wrote:
> > Le dimanche 27 février 2011 à 16:14 +0100, Daniel Lezcano a écrit :
> >> On 02/23/2011 06:13 PM, Andrian Nord wrote:
> >>> On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
> >>>> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
> >>>> or incomplete.
> >>> I'm confirming, that this happens only when macvlan's are onto dummy net
> >>> device. In case of some physical interface under macvlan there is no lost
> >>> packages and no broken checksums.
> >> I did some tests with a 2.6.35 kernel version and it seems the checksum
> >> errors do not appear.
> >> I noticed there are some changes in the dummy setup function:
> >>
> >>     dev->features   |= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
> >>     dev->features   |= NETIF_F_NO_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;
> >>
> >>
> >> May be that was introduced by commit:
> >>
> >> commit 6d81f41c58c69ddde497e9e640ba5805aa26e78c
> >> Author: Eric Dumazet<eric.dumazet@gmail.com>
> >> Date:   Mon Sep 27 20:50:33 2010 +0000
> >>
> >>       dummy: percpu stats and lockless xmit
> >>
> >>       Converts dummy network device driver to :
> >>
> >>       - percpu stats
> >>
> >>       - 64bit stats
> >>
> >>       - lockless xmit (NETIF_F_LLTX)
> >>
> >>       - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
> >>       NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
> >>
> >>       Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> >>       Signed-off-by: David S. Miller<davem@davemloft.net>
> >>
> >>
> >> Eric,
> >>
> >> Andrian is observing, with a couple of macvlan (in bridge mode) on top
> >> of a dummy interface, a lot of checksums error and packets drop.
> >> Each macvlan is in a different network namespace and the dummy interface
> >> is in the init_net.
> >>
> >> Any ideas ?
> > Not sure I understand... I thought dummy was dropping all frames
> > anyway ?
> >
> > static netdev_tx_t dummy_xmit(struct sk_buff *skb, struct net_device *dev)
> > {
> >          struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
> >
> >          u64_stats_update_begin(&dstats->syncp);
> >          dstats->tx_packets++;
> >          dstats->tx_bytes += skb->len;
> >          u64_stats_update_end(&dstats->syncp);
> >
> >          dev_kfree_skb(skb);
> >          return NETDEV_TX_OK;
> > }
> >
> >
> > Maybe you could describe the setup ?
> 
> Yes, it is very simple.
> 
> There are two network namespaces.
> 
> macvlan1 is in network namespace 1
> macvlan2 is in network namespace 2
> 
> Both are in "bridge" mode, so they can communicate together.
> The lower device is dummy0 in the init network namespace.
> 
> IMO the problem is coming from the macvlan driver:
> 
> dev->features           = lowerdev->features & MACVLAN_FEATURES
> 
> As dummy0 has the offloading capabilities set on, the macvlan driver 
> inherit these features.
> 
> In the normal case, dummy0 is supposed to drop the packets. But with 
> macvlan these packets are broadcasted to the other macvlan ports, so no 
> checksum is computed when the packets are transmitted between macvlan1 
> and macvlan2.

So where frames get bad checksums ?

In this "bridge" mode, I suspect the broadcast is done _before_ sending
frame to dummy, so maybe macvlan should not inherit from lowerdev in
this particular case ?

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

[Daniel Lezcano]

On 02/28/2011 08:45 AM, Eric Dumazet wrote:
> Le dimanche 27 février 2011 à 21:35 +0100, Daniel Lezcano a écrit :
>> On 02/27/2011 08:50 PM, Eric Dumazet wrote:
>>> Le dimanche 27 février 2011 à 16:14 +0100, Daniel Lezcano a écrit :
>>>> On 02/23/2011 06:13 PM, Andrian Nord wrote:
>>>>> On Mon, Feb 21, 2011 at 05:07:31PM +0100, Daniel Lezcano wrote:
>>>>>> I Cc'ed the netdev mailing list and Patrick in case my analysis is wrong
>>>>>> or incomplete.
>>>>> I'm confirming, that this happens only when macvlan's are onto dummy net
>>>>> device. In case of some physical interface under macvlan there is no lost
>>>>> packages and no broken checksums.
>>>> I did some tests with a 2.6.35 kernel version and it seems the checksum
>>>> errors do not appear.
>>>> I noticed there are some changes in the dummy setup function:
>>>>
>>>>      dev->features   |= NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO;
>>>>      dev->features   |= NETIF_F_NO_CSUM | NETIF_F_HIGHDMA | NETIF_F_LLTX;
>>>>
>>>>
>>>> May be that was introduced by commit:
>>>>
>>>> commit 6d81f41c58c69ddde497e9e640ba5805aa26e78c
>>>> Author: Eric Dumazet<eric.dumazet@gmail.com>
>>>> Date:   Mon Sep 27 20:50:33 2010 +0000
>>>>
>>>>        dummy: percpu stats and lockless xmit
>>>>
>>>>        Converts dummy network device driver to :
>>>>
>>>>        - percpu stats
>>>>
>>>>        - 64bit stats
>>>>
>>>>        - lockless xmit (NETIF_F_LLTX)
>>>>
>>>>        - performance features added (NETIF_F_SG | NETIF_F_FRAGLIST |
>>>>        NETIF_F_TSO | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA)
>>>>
>>>>        Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>>>>        Signed-off-by: David S. Miller<davem@davemloft.net>
>>>>
>>>>
>>>> Eric,
>>>>
>>>> Andrian is observing, with a couple of macvlan (in bridge mode) on top
>>>> of a dummy interface, a lot of checksums error and packets drop.
>>>> Each macvlan is in a different network namespace and the dummy interface
>>>> is in the init_net.
>>>>
>>>> Any ideas ?
>>> Not sure I understand... I thought dummy was dropping all frames
>>> anyway ?
>>>
>>> static netdev_tx_t dummy_xmit(struct sk_buff *skb, struct net_device *dev)
>>> {
>>>           struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
>>>
>>>           u64_stats_update_begin(&dstats->syncp);
>>>           dstats->tx_packets++;
>>>           dstats->tx_bytes += skb->len;
>>>           u64_stats_update_end(&dstats->syncp);
>>>
>>>           dev_kfree_skb(skb);
>>>           return NETDEV_TX_OK;
>>> }
>>>
>>>
>>> Maybe you could describe the setup ?
>> Yes, it is very simple.
>>
>> There are two network namespaces.
>>
>> macvlan1 is in network namespace 1
>> macvlan2 is in network namespace 2
>>
>> Both are in "bridge" mode, so they can communicate together.
>> The lower device is dummy0 in the init network namespace.
>>
>> IMO the problem is coming from the macvlan driver:
>>
>> dev->features           = lowerdev->features&  MACVLAN_FEATURES
>>
>> As dummy0 has the offloading capabilities set on, the macvlan driver
>> inherit these features.
>>
>> In the normal case, dummy0 is supposed to drop the packets. But with
>> macvlan these packets are broadcasted to the other macvlan ports, so no
>> checksum is computed when the packets are transmitted between macvlan1
>> and macvlan2.
> So where frames get bad checksums ?
>
> In this "bridge" mode, I suspect the broadcast is done _before_ sending
> frame to dummy, so maybe macvlan should not inherit from lowerdev in
> this particular case ?

Hi Eric,

yes, you are right, the packets are sent before.

In the 'macvlan_queue_xmit', the code checks the dev is in 'bridge' 
mode. If so, it looks if there is a destination port for the packet and 
then calls the 'forward' callback which is 'dev_forward_skb'.

I was able to reproduce the same problem with qemu and an emulated 
'e1000' card instead of dummy0. The packets are dropped too.

Patrick, do you have any suggestions to fix this ?

Thanks
   -- Daniel

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

[Patrick McHardy]

On 01.03.2011 14:29, Daniel Lezcano wrote:
> On 02/28/2011 08:45 AM, Eric Dumazet wrote:
>>> In the normal case, dummy0 is supposed to drop the packets. But with
>>> macvlan these packets are broadcasted to the other macvlan ports, so no
>>> checksum is computed when the packets are transmitted between macvlan1
>>> and macvlan2.
>> So where frames get bad checksums ?
>>
>> In this "bridge" mode, I suspect the broadcast is done _before_ sending
>> frame to dummy, so maybe macvlan should not inherit from lowerdev in
>> this particular case ?
> 
> Hi Eric,
> 
> yes, you are right, the packets are sent before.
> 
> In the 'macvlan_queue_xmit', the code checks the dev is in 'bridge'
> mode. If so, it looks if there is a destination port for the packet and
> then calls the 'forward' callback which is 'dev_forward_skb'.
> 
> I was able to reproduce the same problem with qemu and an emulated
> 'e1000' card instead of dummy0. The packets are dropped too.
> 
> 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.

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

[Daniel Lezcano]

On 03/01/2011 05:51 PM, Patrick McHardy wrote:
> On 01.03.2011 14:29, Daniel Lezcano wrote:
>> On 02/28/2011 08:45 AM, Eric Dumazet wrote:
>>>> In the normal case, dummy0 is supposed to drop the packets. But with
>>>> macvlan these packets are broadcasted to the other macvlan ports, so no
>>>> checksum is computed when the packets are transmitted between macvlan1
>>>> and macvlan2.
>>> So where frames get bad checksums ?
>>>
>>> In this "bridge" mode, I suspect the broadcast is done _before_ sending
>>> frame to dummy, so maybe macvlan should not inherit from lowerdev in
>>> this particular case ?
>> Hi Eric,
>>
>> yes, you are right, the packets are sent before.
>>
>> In the 'macvlan_queue_xmit', the code checks the dev is in 'bridge'
>> mode. If so, it looks if there is a destination port for the packet and
>> then calls the 'forward' callback which is 'dev_forward_skb'.
>>
>> I was able to reproduce the same problem with qemu and an emulated
>> 'e1000' card instead of dummy0. The packets are dropped too.
>>
>> 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:

---
  drivers/net/macvlan.c |    1 +
  1 file changed, 1 insertion(+)

Index: linux-next/drivers/net/macvlan.c
===================================================================
--- 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 ?

Thanks

   -- Daniel

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

[Patrick McHardy]

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.

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

[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 ?

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

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

Thanks
   -- Daniel






<javascript:void(0);>

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

[Patrick McHardy]

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.

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

[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 ?

---
  drivers/net/macvlan.c |    3 +++
  1 file changed, 3 insertions(+)

Index: linux-next/drivers/net/macvlan.c
===================================================================
--- linux-next.orig/drivers/net/macvlan.c
+++ linux-next/drivers/net/macvlan.c
@@ -222,10 +222,13 @@ static int macvlan_queue_xmit(struct sk_

         if (vlan->mode == MACVLAN_MODE_BRIDGE) {
                 const struct ethhdr *eth = (void *)skb->data;
+               __u8 ip_summed = skb->ip_summed;
+               skb->ip_summed; = CHECKSUM_UNNECESSARY;

                 /* send to other bridge ports directly */
                 if (is_multicast_ether_addr(eth->h_dest)) {
                         macvlan_broadcast(skb, port, dev, 
MACVLAN_MODE_BRIDGE);
+                       skb->ip_summed = ip_summed;
                         goto xmit_world;
                 }

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

[Changli Gao]

On Thu, Mar 3, 2011 at 2:33 AM, Daniel Lezcano <daniel.lezcano@free.fr> wrote:
>
> 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 ?
>
> ---
>  drivers/net/macvlan.c |    3 +++
>  1 file changed, 3 insertions(+)
>
> Index: linux-next/drivers/net/macvlan.c
> ===================================================================
> --- linux-next.orig/drivers/net/macvlan.c
> +++ linux-next/drivers/net/macvlan.c
> @@ -222,10 +222,13 @@ static int macvlan_queue_xmit(struct sk_
>
>        if (vlan->mode == MACVLAN_MODE_BRIDGE) {
>                const struct ethhdr *eth = (void *)skb->data;
> +               __u8 ip_summed = skb->ip_summed;
> +               skb->ip_summed; = CHECKSUM_UNNECESSARY;

You added a additional ";".


-- 
Regards,
Changli Gao(xiaosuo@gmail.com)

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

[Patrick McHardy]

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.

Re: Bad checksums and lost packets with macvlan on dummy

[Daniel Lezcano]

Hi Patrick,

I noticed another problem with the macvlan driver.

In the function dev_forward_skb the test always succeed in the second 
condition making the packet to be dropped.

...

     if (unlikely(!(dev->flags & IFF_UP) ||
              (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {

...

When tracing I have the following values:

skb->len = 2962
and
dev->mtu + dev->hard_header_len + VLAN_HLEN = 1518

Do you have any idea where that could be come from ?

Thanks

   -- Daniel



On 03/08/2011 03:41 PM, Patrick McHardy wrote:
> 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.



------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

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

[Daniel Lezcano]

On 03/12/2011 10:59 PM, Daniel Lezcano wrote:
>
> Hi Patrick,
>
> I noticed another problem with the macvlan driver.
>
> In the function dev_forward_skb the test always succeed in the second
> condition making the packet to be dropped.
>
> ...
>
>       if (unlikely(!(dev->flags&  IFF_UP) ||
>                (skb->len>  (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
>
> ...
>
> When tracing I have the following values:
>
> skb->len = 2962
> and
> dev->mtu + dev->hard_header_len + VLAN_HLEN = 1518
>
> Do you have any idea where that could be come from ?

Disabling TSO solves the problem. Is it possible the packets are not 
fragmented to the mtu size as it is supposed to be done by the lower 
device but as we are in bridge mode, we dev_forward_skb and the check is 
expecting the packet to be mtu-compliant ?


> On 03/08/2011 03:41 PM, Patrick McHardy wrote:
>> 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.
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Lxc-users mailing list
> Lxc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users