netdev - Re: [PATCH v2 10/14] ixgbe: Update ixgbe to use new vlan accleration.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Oct 2010 17:08:30 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Michał Mirosław <mirqus@...il.com>
Cc:	John Fastabend <john.r.fastabend@...el.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Tantilov, Emil S" <emil.s.tantilov@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: Re: [PATCH v2 10/14] ixgbe: Update ixgbe to use new vlan accleration.

2010/10/25 Michał Mirosław <mirqus@...il.com>:
> W dniu 26 października 2010 00:02 użytkownik John Fastabend
> <john.r.fastabend@...el.com> napisał:
>> On 10/25/2010 2:40 PM, Michał Mirosław wrote:
>>> W dniu 25 października 2010 19:50 użytkownik Peter P Waskiewicz Jr
>>> <peter.p.waskiewicz.jr@...el.com> napisał:
>>>> On Fri, 2010-10-22 at 06:24 -0700, Michał Mirosław wrote:
>>>>> 2010/10/21 Jesse Gross <jesse@...ira.com>:
>>>>>> Make the ixgbe driver use the new vlan accleration model.
>>>>> [...]
>>>>>> --- a/drivers/net/ixgbe/ixgbe_main.c
>>>>>> +++ b/drivers/net/ixgbe/ixgbe_main.c
>>>>>> @@ -954,17 +954,13 @@ static void ixgbe_receive_skb(struct ixgbe_q_vector *q_vector,
>>>>>>        bool is_vlan = (status & IXGBE_RXD_STAT_VP);
>>>>>>        u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
>>>>>>
>>>>>> -       if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL)) {
>>>>>> -               if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
>>>>>> -                       vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
>>>>>> -               else
>>>>>> -                       napi_gro_receive(napi, skb);
>>>>>> -       } else {
>>>>>> -               if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
>>>>>> -                       vlan_hwaccel_rx(skb, adapter->vlgrp, tag);
>>>>>> -               else
>>>>>> -                       netif_rx(skb);
>>>>>> -       }
>>>>>> +       if (is_vlan && (tag & VLAN_VID_MASK))
>>>>>> +               __vlan_hwaccel_put_tag(skb, tag);
>>>>>
>>>>> I know that this is carried over from the driver, but why tag == 0 is
>>>>> treated differently here? VID0 is somewhat special, as normally it
>>>>> means 802.1p packet, but i.e. in embedded world people are using it as
>>>>> normal VID. It would be nice to have this handled consistently in the
>>>>> VLAN core - deliver to base dev (tag stripped) if vlan 0 is not
>>>>> configured and to vlan dev if it is.
>>>>
>>>> ixgbe handles VLAN 0 differently because that's the tag that's used when
>>>> DCB is enabled, and no VLAN is configured.  We have to insert the 802.1p
>>>> tag for DCB to work, but the OS won't know about the 802.1q tag, and
>>>> ends up dropping the frame.  So we enable VLAN ID 0 in the HW and tell
>>>> it to strip the tag, so we can still pass the frame up the stack.
>>>
>>> So that's actually (part of) what I'm proposing but done at driver level.
>> I agree this should be handled outside the driver. Something like this should
>> do,
>
> Current code (Linus' tree, so with Jesse's VLAN rework applied) should
> work exactly as I proposed in my original mail - VLAN 0 is treated as
> 802.1p (stripped and delivered to original dev) unless vlan device
> with id 0 is configured. (Patch untested).

Yes, the current vlan acceleration path should work correctly in this
case.  There are definitely a few things that can be improved though:

1. The non-accelerated path doesn't handle things in the same way,
which is inherently not good.  It doesn't drop packets to vlan 0 but
it does run them through the network stack again on the same device.
The acceleration code simply allows it to continue onto the protocol
handlers.  This can have strange results, i.e. packets will show up
twice in tcpdump (tagged and untagged) on non-accelerated but once
(tagged) on accelerated.

2.  In the ixgbe driver we should be able to handle vlan 0 in a less
special manner.  In addition to delivering accelerated tags to vlan 0,
we should also be able to avoid DCB forcing on vlan stripping.
--
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