Patchwork [v2,10/14] ixgbe: Update ixgbe to use new vlan accleration.

login
register
mail settings
Submitter =?ISO-8859-2?Q?Micha=B3_Miros=B3aw?=
Date Oct. 25, 2010, 11:23 p.m.
Message ID <AANLkTim68bfo54XsoPbbDUGa4evPA2vSmJbSTs-LZv=Q@mail.gmail.com>
Download mbox | patch
Permalink /patch/69149/
State RFC
Delegated to: David Miller
Headers show

Comments

=?ISO-8859-2?Q?Micha=B3_Miros=B3aw?= - Oct. 25, 2010, 11:23 p.m.
W dniu 26 października 2010 00:02 użytkownik John Fastabend
<john.r.fastabend@intel.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@intel.com> napisał:
>>> On Fri, 2010-10-22 at 06:24 -0700, Michał Mirosław wrote:
>>>> 2010/10/21 Jesse Gross <jesse@nicira.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).

Best Regards,
Michał Mirosław
---

ixgbe: Enable VLAN 0

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>

 	if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL))
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jesse Gross - Oct. 26, 2010, 12:08 a.m.
2010/10/25 Michał Mirosław <mirqus@gmail.com>:
> W dniu 26 października 2010 00:02 użytkownik John Fastabend
> <john.r.fastabend@intel.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@intel.com> napisał:
>>>> On Fri, 2010-10-22 at 06:24 -0700, Michał Mirosław wrote:
>>>>> 2010/10/21 Jesse Gross <jesse@nicira.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index f856312..1544368 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -956,7 +956,7 @@  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 (is_vlan && (tag & VLAN_VID_MASK))
+	if (is_vlan)
 		__vlan_hwaccel_put_tag(skb, tag);