[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SJ0PR18MB5216C33138C7067A24BD4DE4DB81A@SJ0PR18MB5216.namprd18.prod.outlook.com>
Date: Fri, 1 Dec 2023 16:16:52 +0000
From: Suman Ghosh <sumang@...vell.com>
To: Kurt Kanzenbach <kurt@...utronix.de>,
Jesse Brandeburg
<jesse.brandeburg@...el.com>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>
CC: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni
<pabeni@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [EXT] [PATCH iwl-net v2 1/2] igc: Report VLAN EtherType matching
back to user
>Hi Kurt,
>
>
>>+ if (rule->filter.match_flags & IGC_FILTER_FLAG_VLAN_ETYPE) {
>>+ fsp->flow_type |= FLOW_EXT;
>>+ fsp->h_ext.vlan_etype = rule->filter.vlan_etype;
>>+ fsp->m_ext.vlan_etype = ETHER_TYPE_FULL_MASK;
>[Suman] User can provide mask for vlan-etype as well. Why not take that
>rather than hard coding it? I checked you are already doing the same for
>TCI in the other patch.
Currently the driver allows/supports to match the VLAN EtherType only by
full mask. That is different from TCI, where two different mask values
are possible.
Thanks,
Kurt
>>+ }
[Suman] It is up to you. But I feel, in that case we should have some checks to reject the ntuple rule if user is providing some valid mask value. Otherwise, there will be mismatch between user expectation and driver functionality.
>>+
>> if (rule->filter.match_flags & IGC_FILTER_FLAG_VLAN_TCI) {
>> fsp->flow_type |= FLOW_EXT;
>> fsp->h_ext.vlan_tci = htons(rule->filter.vlan_tci);
>>--
>>2.39.2
>>
Powered by blists - more mailing lists