[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220712173110.GB3794@localhost.localdomain>
Date: Tue, 12 Jul 2022 19:31:10 +0200
From: Guillaume Nault <gnault@...hat.com>
To: "Drewek, Wojciech" <wojciech.drewek@...el.com>
Cc: Marcin Szycik <marcin.szycik@...ux.intel.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
"gustavoars@...nel.org" <gustavoars@...nel.org>,
"baowen.zheng@...igine.com" <baowen.zheng@...igine.com>,
"boris.sukholitko@...adcom.com" <boris.sukholitko@...adcom.com>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"jhs@...atatu.com" <jhs@...atatu.com>,
"jiri@...nulli.us" <jiri@...nulli.us>,
"kurt@...utronix.de" <kurt@...utronix.de>,
"pablo@...filter.org" <pablo@...filter.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"paulb@...dia.com" <paulb@...dia.com>,
"simon.horman@...igine.com" <simon.horman@...igine.com>,
"komachi.yoshiki@...il.com" <komachi.yoshiki@...il.com>,
"zhangkaiheb@....com" <zhangkaiheb@....com>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"michal.swiatkowski@...ux.intel.com"
<michal.swiatkowski@...ux.intel.com>,
"Lobakin, Alexandr" <alexandr.lobakin@...el.com>,
"mostrows@...thlink.net" <mostrows@...thlink.net>,
"paulus@...ba.org" <paulus@...ba.org>
Subject: Re: [RFC PATCH net-next v4 2/4] net/sched: flower: Add PPPoE filter
On Mon, Jul 11, 2022 at 10:26:21AM +0000, Drewek, Wojciech wrote:
> > > +static void fl_set_key_pppoe(struct nlattr **tb,
> > > + struct flow_dissector_key_pppoe *key_val,
> > > + struct flow_dissector_key_pppoe *key_mask,
> > > + struct fl_flow_key *key,
> > > + struct fl_flow_key *mask)
> > > +{
> > > + /* key_val::type must be set to ETH_P_PPP_SES
> > > + * because ETH_P_PPP_SES was stored in basic.n_proto
> > > + * which might get overwritten by ppp_proto
> > > + * or might be set to 0, the role of key_val::type
> > > + * is simmilar to vlan_key::tpid
> >
> > Didn't you mean "vlan_tpid"?
>
> Yes, is vlan_key::tpid not clear/valid?
At least it wasn't entirely clear to me as I wondered if I got the
comment right. And it's basically free to use the real name of the
structure field.
Powered by blists - more mailing lists