From: Guillaume Nault <gnault@redhat.com> To: Marcin Szycik <marcin.szycik@linux.intel.com> Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com, davem@davemloft.net, xiyou.wangcong@gmail.com, jesse.brandeburg@intel.com, gustavoars@kernel.org, baowen.zheng@corigine.com, boris.sukholitko@broadcom.com, edumazet@google.com, kuba@kernel.org, jhs@mojatatu.com, jiri@resnulli.us, kurt@linutronix.de, pablo@netfilter.org, pabeni@redhat.com, paulb@nvidia.com, simon.horman@corigine.com, komachi.yoshiki@gmail.com, zhangkaiheb@126.com, intel-wired-lan@lists.osuosl.org, michal.swiatkowski@linux.intel.com, wojciech.drewek@intel.com, alexandr.lobakin@intel.com, mostrows@earthlink.net, paulus@samba.org Subject: Re: [RFC PATCH net-next v3 1/4] flow_dissector: Add PPPoE dissectors Date: Fri, 1 Jul 2022 01:10:16 +0200 [thread overview] Message-ID: <20220630231016.GA392@debian.home> (raw) In-Reply-To: <20220629143859.209028-2-marcin.szycik@linux.intel.com> On Wed, Jun 29, 2022 at 04:38:56PM +0200, Marcin Szycik wrote: > From: Wojciech Drewek <wojciech.drewek@intel.com> > > Allow to dissect PPPoE specific fields which are: > - session ID (16 bits) > - ppp protocol (16 bits) > > The goal is to make the following TC command possible: > > # tc filter add dev ens6f0 ingress prio 1 protocol ppp_ses \ > flower \ > pppoe_sid 12 \ > ppp_proto ip \ > action drop > > Note that only PPPoE Session is supported. > > Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> > --- > v3: revert byte order changes in is_ppp_proto_supported from previous > version, add kernel-doc for is_ppp_proto_supported > v2: use ntohs instead of htons in is_ppp_proto_supported > > include/net/flow_dissector.h | 11 ++++++++ > net/core/flow_dissector.c | 55 ++++++++++++++++++++++++++++++++---- > 2 files changed, 60 insertions(+), 6 deletions(-) > > diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h > index a4c6057c7097..8ff40c7c3f1c 100644 > --- a/include/net/flow_dissector.h > +++ b/include/net/flow_dissector.h > @@ -261,6 +261,16 @@ struct flow_dissector_key_num_of_vlans { > u8 num_of_vlans; > }; > > +/** > + * struct flow_dissector_key_pppoe: > + * @session_id: pppoe session id > + * @ppp_proto: ppp protocol > + */ > +struct flow_dissector_key_pppoe { > + u16 session_id; > + __be16 ppp_proto; > +}; Why isn't session_id __be16 too? Also, I'm not sure I like mixing the PPPoE session ID and PPP protocol fields in the same structure: they're part of two different protocols. However, I can't anticipate any technical problem in doing so, and I guess there's no easy way to let the flow dissector parse the PPP header independently. So well, maybe we don't have choice... > enum flow_dissector_key_id { > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */ > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */ > @@ -291,6 +301,7 @@ enum flow_dissector_key_id { > FLOW_DISSECTOR_KEY_CT, /* struct flow_dissector_key_ct */ > FLOW_DISSECTOR_KEY_HASH, /* struct flow_dissector_key_hash */ > FLOW_DISSECTOR_KEY_NUM_OF_VLANS, /* struct flow_dissector_key_num_of_vlans */ > + FLOW_DISSECTOR_KEY_PPPOE, /* struct flow_dissector_key_pppoe */ > > FLOW_DISSECTOR_KEY_MAX, > }; > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c > index 6aee04f75e3e..42393af477a2 100644 > --- a/net/core/flow_dissector.c > +++ b/net/core/flow_dissector.c > @@ -895,6 +895,39 @@ bool bpf_flow_dissect(struct bpf_prog *prog, struct bpf_flow_dissector *ctx, > return result == BPF_OK; > } > > +/** > + * is_ppp_proto_supported - checks if inner PPP protocol should be dissected > + * @proto: protocol type (PPP proto field) > + */ > +static bool is_ppp_proto_supported(__be16 proto) > +{ > + switch (proto) { > + case htons(PPP_AT): > + case htons(PPP_IPX): > + case htons(PPP_VJC_COMP): > + case htons(PPP_VJC_UNCOMP): > + case htons(PPP_MP): > + case htons(PPP_COMPFRAG): > + case htons(PPP_COMP): > + case htons(PPP_MPLS_UC): > + case htons(PPP_MPLS_MC): > + case htons(PPP_IPCP): > + case htons(PPP_ATCP): > + case htons(PPP_IPXCP): > + case htons(PPP_IPV6CP): > + case htons(PPP_CCPFRAG): > + case htons(PPP_MPLSCP): > + case htons(PPP_LCP): > + case htons(PPP_PAP): > + case htons(PPP_LQR): > + case htons(PPP_CHAP): > + case htons(PPP_CBCP): > + return true; > + default: > + return false; > + } > +} > + > /** > * __skb_flow_dissect - extract the flow_keys struct and return it > * @net: associated network namespace, derived from @skb if NULL > @@ -1221,19 +1254,29 @@ bool __skb_flow_dissect(const struct net *net, > } > > nhoff += PPPOE_SES_HLEN; > - switch (hdr->proto) { > - case htons(PPP_IP): > + if (hdr->proto == htons(PPP_IP)) { > proto = htons(ETH_P_IP); > fdret = FLOW_DISSECT_RET_PROTO_AGAIN; > - break; > - case htons(PPP_IPV6): > + } else if (hdr->proto == htons(PPP_IPV6)) { > proto = htons(ETH_P_IPV6); > fdret = FLOW_DISSECT_RET_PROTO_AGAIN; > - break; 1) Looks like you could easily handle MPLS too. Did you skip it on purpose? (not enough users to justify writing and maintaining the code?). I don't mean MPLS has to be supported; I'd just like to know if it was considered. 2) Also this whole test is a bit weak: the version, type and code fields must have precise values for the PPPoE Session packet to be valid. If either version or type is different than 1, then the packet advertises a new version of the protocol that we don't know how to parse (or most probably the packet was forged or corrupted). A non-zero code is also invalid. I know the code was already like this before your patch, but it's probably better to fix it before implementing hardware offload. 3) Finally, the PPP protocol could be compressed and stored in 1 byte instead of 2. This case wasn't handled before your patch, but I think that should be fixed too before implementing hardware offload. > - default: > + } else if (is_ppp_proto_supported(hdr->proto)) { > + fdret = FLOW_DISSECT_RET_OUT_GOOD; > + } else { > fdret = FLOW_DISSECT_RET_OUT_BAD; > break; > } > + > + if (dissector_uses_key(flow_dissector, > + FLOW_DISSECTOR_KEY_PPPOE)) { > + struct flow_dissector_key_pppoe *key_pppoe; > + > + key_pppoe = skb_flow_dissector_target(flow_dissector, > + FLOW_DISSECTOR_KEY_PPPOE, > + target_container); > + key_pppoe->session_id = ntohs(hdr->hdr.sid); > + key_pppoe->ppp_proto = hdr->proto; > + } > break; > } > case htons(ETH_P_TIPC): { > -- > 2.35.1 >
WARNING: multiple messages have this Message-ID (diff)
From: Guillaume Nault <gnault@redhat.com> To: Marcin Szycik <marcin.szycik@linux.intel.com> Cc: simon.horman@corigine.com, kurt@linutronix.de, paulb@nvidia.com, edumazet@google.com, boris.sukholitko@broadcom.com, jiri@resnulli.us, paulus@samba.org, jesse.brandeburg@intel.com, intel-wired-lan@lists.osuosl.org, kuba@kernel.org, zhangkaiheb@126.com, pablo@netfilter.org, baowen.zheng@corigine.com, komachi.yoshiki@gmail.com, jhs@mojatatu.com, mostrows@earthlink.net, xiyou.wangcong@gmail.com, pabeni@redhat.com, netdev@vger.kernel.org, gustavoars@kernel.org, davem@davemloft.net Subject: Re: [Intel-wired-lan] [RFC PATCH net-next v3 1/4] flow_dissector: Add PPPoE dissectors Date: Fri, 1 Jul 2022 01:10:16 +0200 [thread overview] Message-ID: <20220630231016.GA392@debian.home> (raw) In-Reply-To: <20220629143859.209028-2-marcin.szycik@linux.intel.com> On Wed, Jun 29, 2022 at 04:38:56PM +0200, Marcin Szycik wrote: > From: Wojciech Drewek <wojciech.drewek@intel.com> > > Allow to dissect PPPoE specific fields which are: > - session ID (16 bits) > - ppp protocol (16 bits) > > The goal is to make the following TC command possible: > > # tc filter add dev ens6f0 ingress prio 1 protocol ppp_ses \ > flower \ > pppoe_sid 12 \ > ppp_proto ip \ > action drop > > Note that only PPPoE Session is supported. > > Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> > --- > v3: revert byte order changes in is_ppp_proto_supported from previous > version, add kernel-doc for is_ppp_proto_supported > v2: use ntohs instead of htons in is_ppp_proto_supported > > include/net/flow_dissector.h | 11 ++++++++ > net/core/flow_dissector.c | 55 ++++++++++++++++++++++++++++++++---- > 2 files changed, 60 insertions(+), 6 deletions(-) > > diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h > index a4c6057c7097..8ff40c7c3f1c 100644 > --- a/include/net/flow_dissector.h > +++ b/include/net/flow_dissector.h > @@ -261,6 +261,16 @@ struct flow_dissector_key_num_of_vlans { > u8 num_of_vlans; > }; > > +/** > + * struct flow_dissector_key_pppoe: > + * @session_id: pppoe session id > + * @ppp_proto: ppp protocol > + */ > +struct flow_dissector_key_pppoe { > + u16 session_id; > + __be16 ppp_proto; > +}; Why isn't session_id __be16 too? Also, I'm not sure I like mixing the PPPoE session ID and PPP protocol fields in the same structure: they're part of two different protocols. However, I can't anticipate any technical problem in doing so, and I guess there's no easy way to let the flow dissector parse the PPP header independently. So well, maybe we don't have choice... > enum flow_dissector_key_id { > FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */ > FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */ > @@ -291,6 +301,7 @@ enum flow_dissector_key_id { > FLOW_DISSECTOR_KEY_CT, /* struct flow_dissector_key_ct */ > FLOW_DISSECTOR_KEY_HASH, /* struct flow_dissector_key_hash */ > FLOW_DISSECTOR_KEY_NUM_OF_VLANS, /* struct flow_dissector_key_num_of_vlans */ > + FLOW_DISSECTOR_KEY_PPPOE, /* struct flow_dissector_key_pppoe */ > > FLOW_DISSECTOR_KEY_MAX, > }; > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c > index 6aee04f75e3e..42393af477a2 100644 > --- a/net/core/flow_dissector.c > +++ b/net/core/flow_dissector.c > @@ -895,6 +895,39 @@ bool bpf_flow_dissect(struct bpf_prog *prog, struct bpf_flow_dissector *ctx, > return result == BPF_OK; > } > > +/** > + * is_ppp_proto_supported - checks if inner PPP protocol should be dissected > + * @proto: protocol type (PPP proto field) > + */ > +static bool is_ppp_proto_supported(__be16 proto) > +{ > + switch (proto) { > + case htons(PPP_AT): > + case htons(PPP_IPX): > + case htons(PPP_VJC_COMP): > + case htons(PPP_VJC_UNCOMP): > + case htons(PPP_MP): > + case htons(PPP_COMPFRAG): > + case htons(PPP_COMP): > + case htons(PPP_MPLS_UC): > + case htons(PPP_MPLS_MC): > + case htons(PPP_IPCP): > + case htons(PPP_ATCP): > + case htons(PPP_IPXCP): > + case htons(PPP_IPV6CP): > + case htons(PPP_CCPFRAG): > + case htons(PPP_MPLSCP): > + case htons(PPP_LCP): > + case htons(PPP_PAP): > + case htons(PPP_LQR): > + case htons(PPP_CHAP): > + case htons(PPP_CBCP): > + return true; > + default: > + return false; > + } > +} > + > /** > * __skb_flow_dissect - extract the flow_keys struct and return it > * @net: associated network namespace, derived from @skb if NULL > @@ -1221,19 +1254,29 @@ bool __skb_flow_dissect(const struct net *net, > } > > nhoff += PPPOE_SES_HLEN; > - switch (hdr->proto) { > - case htons(PPP_IP): > + if (hdr->proto == htons(PPP_IP)) { > proto = htons(ETH_P_IP); > fdret = FLOW_DISSECT_RET_PROTO_AGAIN; > - break; > - case htons(PPP_IPV6): > + } else if (hdr->proto == htons(PPP_IPV6)) { > proto = htons(ETH_P_IPV6); > fdret = FLOW_DISSECT_RET_PROTO_AGAIN; > - break; 1) Looks like you could easily handle MPLS too. Did you skip it on purpose? (not enough users to justify writing and maintaining the code?). I don't mean MPLS has to be supported; I'd just like to know if it was considered. 2) Also this whole test is a bit weak: the version, type and code fields must have precise values for the PPPoE Session packet to be valid. If either version or type is different than 1, then the packet advertises a new version of the protocol that we don't know how to parse (or most probably the packet was forged or corrupted). A non-zero code is also invalid. I know the code was already like this before your patch, but it's probably better to fix it before implementing hardware offload. 3) Finally, the PPP protocol could be compressed and stored in 1 byte instead of 2. This case wasn't handled before your patch, but I think that should be fixed too before implementing hardware offload. > - default: > + } else if (is_ppp_proto_supported(hdr->proto)) { > + fdret = FLOW_DISSECT_RET_OUT_GOOD; > + } else { > fdret = FLOW_DISSECT_RET_OUT_BAD; > break; > } > + > + if (dissector_uses_key(flow_dissector, > + FLOW_DISSECTOR_KEY_PPPOE)) { > + struct flow_dissector_key_pppoe *key_pppoe; > + > + key_pppoe = skb_flow_dissector_target(flow_dissector, > + FLOW_DISSECTOR_KEY_PPPOE, > + target_container); > + key_pppoe->session_id = ntohs(hdr->hdr.sid); > + key_pppoe->ppp_proto = hdr->proto; > + } > break; > } > case htons(ETH_P_TIPC): { > -- > 2.35.1 > _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2022-06-30 23:10 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-29 14:38 [RFC PATCH net-next v3 0/4] ice: PPPoE offload support Marcin Szycik 2022-06-29 14:38 ` [Intel-wired-lan] " Marcin Szycik 2022-06-29 14:38 ` [RFC PATCH net-next v3 1/4] flow_dissector: Add PPPoE dissectors Marcin Szycik 2022-06-29 14:38 ` [Intel-wired-lan] " Marcin Szycik 2022-06-30 23:10 ` Guillaume Nault [this message] 2022-06-30 23:10 ` Guillaume Nault 2022-07-01 10:53 ` Drewek, Wojciech 2022-07-01 10:53 ` [Intel-wired-lan] " Drewek, Wojciech 2022-07-01 12:41 ` Guillaume Nault 2022-07-01 12:41 ` [Intel-wired-lan] " Guillaume Nault 2022-07-01 13:33 ` Drewek, Wojciech 2022-07-01 13:33 ` [Intel-wired-lan] " Drewek, Wojciech 2022-06-29 14:38 ` [RFC PATCH net-next v3 2/4] net/sched: flower: Add PPPoE filter Marcin Szycik 2022-06-29 14:38 ` [Intel-wired-lan] " Marcin Szycik 2022-06-30 23:11 ` Guillaume Nault 2022-06-30 23:11 ` [Intel-wired-lan] " Guillaume Nault 2022-06-29 14:38 ` [RFC PATCH net-next v3 3/4] flow_offload: Introduce flow_match_pppoe Marcin Szycik 2022-06-29 14:38 ` [Intel-wired-lan] " Marcin Szycik 2022-06-29 14:38 ` [RFC PATCH net-next v3 4/4] ice: Add support for PPPoE hardware offload Marcin Szycik 2022-06-29 14:38 ` [Intel-wired-lan] " Marcin Szycik 2022-06-30 23:12 ` Guillaume Nault 2022-06-30 23:12 ` [Intel-wired-lan] " Guillaume Nault 2022-07-01 16:12 ` Marcin Szycik 2022-07-01 16:12 ` [Intel-wired-lan] " Marcin Szycik 2022-07-05 9:54 ` Marcin Szycik 2022-07-05 9:54 ` Marcin Szycik 2022-07-07 14:14 ` Guillaume Nault 2022-07-07 14:14 ` [Intel-wired-lan] " Guillaume Nault
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=20220630231016.GA392@debian.home \ --to=gnault@redhat.com \ --cc=alexandr.lobakin@intel.com \ --cc=anthony.l.nguyen@intel.com \ --cc=baowen.zheng@corigine.com \ --cc=boris.sukholitko@broadcom.com \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=gustavoars@kernel.org \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=jesse.brandeburg@intel.com \ --cc=jhs@mojatatu.com \ --cc=jiri@resnulli.us \ --cc=komachi.yoshiki@gmail.com \ --cc=kuba@kernel.org \ --cc=kurt@linutronix.de \ --cc=marcin.szycik@linux.intel.com \ --cc=michal.swiatkowski@linux.intel.com \ --cc=mostrows@earthlink.net \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=pablo@netfilter.org \ --cc=paulb@nvidia.com \ --cc=paulus@samba.org \ --cc=simon.horman@corigine.com \ --cc=wojciech.drewek@intel.com \ --cc=xiyou.wangcong@gmail.com \ --cc=zhangkaiheb@126.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.