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 _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users