From: Jiri Pirko <jiri@resnulli.us>
To: Hadar Hen Zion <hadarh@dev.mellanox.co.il>
Cc: Hadar Hen Zion <hadarh@mellanox.com>,
"David S. Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>, Jiri Pirko <jiri@mellanox.com>,
Amir Vadai <amirva@mellanox.com>,
Or Gerlitz <ogerlitz@mellanox.com>,
Tom Herbert <tom@herbertland.com>
Subject: Re: [PATCH net-next V2 1/5] flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci
Date: Wed, 17 Aug 2016 15:02:47 +0200 [thread overview]
Message-ID: <20160817130247.GE1956@nanopsycho> (raw)
In-Reply-To: <CAJL1qvEDgd2r-iggQ5W-uvYVsWN-uQGN7ab5gN_J26Sk7-=O=g@mail.gmail.com>
Wed, Aug 17, 2016 at 01:05:33PM CEST, hadarh@dev.mellanox.co.il wrote:
>On Wed, Aug 17, 2016 at 1:46 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, Aug 17, 2016 at 12:36:10PM CEST, hadarh@mellanox.com wrote:
>>>Early in the datapath skb_vlan_untag function is called, stripped
>>>the vlan from the skb and set skb->vlan_tci and skb->vlan_proto fields.
>>>
>>>The current dissection doesn't handle stripped vlan packets correctly.
>>>In some flows, vlan doesn't exist in skb->data anymore when applying
>>>flow dissection on the skb, fix that.
>>>
>>>In case vlan info wasn't stripped before applying flow_dissector (RPS
>>>flow for example), or in case of skb with multiple vlans (e.g. 802.1ad),
>>>get the vlan info from skb->data. The flow_dissector correctly skips
>>>any number of vlans and stores only the first level vlan.
>>>
>>>Fixes: 0744dd00c1b1 ('net: introduce skb_flow_dissect()')
>>>Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
>>>---
>>> net/core/flow_dissector.c | 34 ++++++++++++++++++++++++++--------
>>> 1 file changed, 26 insertions(+), 8 deletions(-)
>>>
>>>diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>>>index 91028ae..362d693 100644
>>>--- a/net/core/flow_dissector.c
>>>+++ b/net/core/flow_dissector.c
>>>@@ -119,12 +119,14 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>>> struct flow_dissector_key_ports *key_ports;
>>> struct flow_dissector_key_tags *key_tags;
>>> struct flow_dissector_key_keyid *key_keyid;
>>>+ bool skip_vlan = false;
>>> u8 ip_proto = 0;
>>> bool ret = false;
>>>
>>> if (!data) {
>>> data = skb->data;
>>>- proto = skb->protocol;
>>>+ proto = skb_vlan_tag_present(skb) ?
>>>+ skb->vlan_proto : skb->protocol;
>>> nhoff = skb_network_offset(skb);
>>> hlen = skb_headlen(skb);
>>> }
>>>@@ -243,23 +245,39 @@ ipv6:
>>> case htons(ETH_P_8021AD):
>>> case htons(ETH_P_8021Q): {
>>> const struct vlan_hdr *vlan;
>>>- struct vlan_hdr _vlan;
>>>
>>>- vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan), data, hlen, &_vlan);
>>>- if (!vlan)
>>>- goto out_bad;
>>>+ if (skb_vlan_tag_present(skb))
>>>+ proto = skb->protocol;
>>>+
>>>+ if (!skb_vlan_tag_present(skb) ||
>>>+ proto == cpu_to_be16(ETH_P_8021Q) ||
>>>+ proto == cpu_to_be16(ETH_P_8021AD)) {
>>
>> How this can happen? Could you give me an example?
>>
>
>This can happen in 2 cases:
>
>1. vlan wasn't stripped yet from the skb.
>In RPS flow for example, get_rps_cpu function is using flow-dissector
>before vlan_untag is called by __netif_receive_skb_core.
right, sigh...
>
>2. skb with multiple vlan tags.
>Only the first vlan is stripped while the inner vlans are still in skb->data.
>In this case skb->vlan_proto is 802.1AD and skb->protocol is 802.1Q
>(for example) so I have to take the next header from skb->data.
Hmm I think that whoever removes the outermost vlan from skb->vlan_*
should strip the next header into skb->vlan_*
next prev parent reply other threads:[~2016-08-17 13:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 10:36 [PATCH net-next V2 0/5] net_sched, flow_dissector, flower: Introduce vlan tag support Hadar Hen Zion
2016-08-17 10:36 ` [PATCH net-next V2 1/5] flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci Hadar Hen Zion
2016-08-17 10:46 ` Jiri Pirko
2016-08-17 11:05 ` Hadar Hen Zion
2016-08-17 13:02 ` Jiri Pirko [this message]
2016-08-18 6:22 ` Hadar Hen Zion
2016-08-18 6:46 ` Jiri Pirko
2016-08-18 7:24 ` Jiri Pirko
2016-08-17 10:36 ` [PATCH net-next V2 2/5] flow_dissector: Get vlan priority in addition to vlan id Hadar Hen Zion
2016-08-18 7:25 ` Jiri Pirko
2016-08-17 10:36 ` [PATCH net-next V2 3/5] net_sched: flower: Avoid dissection of unmasked keys Hadar Hen Zion
2016-08-17 10:36 ` [PATCH net-next V2 4/5] net_sched: flower: Add vlan support Hadar Hen Zion
2016-08-17 10:36 ` [PATCH net-next V2 5/5] net_sched: act_vlan: Add priority option Hadar Hen Zion
2016-08-19 6:14 ` [PATCH net-next V2 0/5] net_sched, flow_dissector, flower: Introduce vlan tag support David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160817130247.GE1956@nanopsycho \
--to=jiri@resnulli.us \
--cc=amirva@mellanox.com \
--cc=davem@davemloft.net \
--cc=hadarh@dev.mellanox.co.il \
--cc=hadarh@mellanox.com \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=tom@herbertland.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox