From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Toshiaki Makita <toshiaki.makita1@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, bpf@vger.kernel.org,
cake@lists.bufferbloat.net, Davide Caratti <dcaratti@redhat.com>,
Jiri Pirko <jiri@resnulli.us>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
Roman Mashak <mrv@mojatatu.com>, Lawrence Brakmo <brakmo@fb.com>,
Ilya Ponetayev <i.ponetaev@ndmsystems.com>
Subject: Re: [Cake] [PATCH net v3] sched: consistently handle layer3 header accesses in the presence of VLANs
Date: Sat, 04 Jul 2020 13:33:42 +0200 [thread overview]
Message-ID: <878sfzms4p.fsf@toke.dk> (raw)
In-Reply-To: <ada37763-16cd-7b51-f9ce-41e8d313bf96@gmail.com>
Toshiaki Makita <toshiaki.makita1@gmail.com> writes:
> On 2020/07/04 5:26, Toke Høiland-Jørgensen wrote:
> ...
>> +/* A getter for the SKB protocol field which will handle VLAN tags consistently
>> + * whether VLAN acceleration is enabled or not.
>> + */
>> +static inline __be16 skb_protocol(const struct sk_buff *skb, bool skip_vlan)
>> +{
>> + unsigned int offset = skb_mac_offset(skb) + sizeof(struct ethhdr);
>> + __be16 proto = skb->protocol;
>> +
>> + if (!skip_vlan)
>> + /* VLAN acceleration strips the VLAN header from the skb and
>> + * moves it to skb->vlan_proto
>> + */
>> + return skb_vlan_tag_present(skb) ? skb->vlan_proto : proto;
>> +
>> + while (eth_type_vlan(proto)) {
>> + struct vlan_hdr vhdr, *vh;
>> +
>> + vh = skb_header_pointer(skb, offset, sizeof(vhdr), &vhdr);
>> + if (!vh)
>> + break;
>> +
>> + proto = vh->h_vlan_encapsulated_proto;
>> + offset += sizeof(vhdr);
>> + }
>
> Why don't you use __vlan_get_protocol() here? It looks quite similar.
> Is there any problem with using that?
TBH, I completely missed that helper. It seems to have side effects,
though (pskb_may_pull()), which is one of the things the original patch
to sch_cake that initiated all of this was trying to avoid.
I guess I could just fix that, though, and switch __vlan_get_protocol()
over to using skb_header_pointer(). Will send a follow-up to do that.
Any opinion on whether it's a good idea to limit the max parse depth
while I'm at it (see Daniel's reply)?
-Toke
next prev parent reply other threads:[~2020-07-04 11:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 20:26 Toke Høiland-Jørgensen
2020-07-03 21:35 ` David Miller
2020-07-03 22:17 ` Daniel Borkmann
2020-07-04 11:28 ` Toke Høiland-Jørgensen
2020-07-04 3:24 ` Toshiaki Makita
2020-07-04 11:33 ` Toke Høiland-Jørgensen [this message]
2020-07-06 4:24 ` Toshiaki Makita
2020-07-06 10:53 ` Toke Høiland-Jørgensen
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
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sfzms4p.fsf@toke.dk \
--to=toke@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=brakmo@fb.com \
--cc=cake@lists.bufferbloat.net \
--cc=davem@davemloft.net \
--cc=dcaratti@redhat.com \
--cc=i.ponetaev@ndmsystems.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=mrv@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=toshiaki.makita1@gmail.com \
--cc=xiyou.wangcong@gmail.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