From: Jakub Slepecki <jakub.slepecki@intel.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@intel.com>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
"michal.swiatkowski@linux.intel.com"
<michal.swiatkowski@linux.intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next 4/8] ice: allow overriding lan_en, lb_en in switch
Date: Mon, 24 Nov 2025 11:20:11 +0100 [thread overview]
Message-ID: <ef41487b-ecfb-4b25-83a2-c97d6aa3c813@intel.com> (raw)
In-Reply-To: <IA3PR11MB89860CA2EBCCEDDF0C9E05D9E5D5A@IA3PR11MB8986.namprd11.prod.outlook.com>
On 2025-11-21 10:21, Loktionov, Aleksandr wrote:
>> -----Original Message-----
>> diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c
>> b/drivers/net/ethernet/intel/ice/ice_switch.c
>> index 04e5d653efce..7b63588948fd 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_switch.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_switch.c
>> @@ -2538,8 +2538,9 @@ int ice_get_initial_sw_cfg(struct ice_hw *hw)
>> */
>> static void ice_fill_sw_info(struct ice_hw *hw, struct ice_fltr_info
>> *fi) {
>> - fi->lb_en = false;
>> - fi->lan_en = false;
>> + bool lan_en = false;
>> + bool lb_en = false;
>> +
>> if ((fi->flag & ICE_FLTR_TX) &&
>> (fi->fltr_act == ICE_FWD_TO_VSI ||
>> fi->fltr_act == ICE_FWD_TO_VSI_LIST || @@ -2549,7 +2550,7
>> @@ static void ice_fill_sw_info(struct ice_hw *hw, struct
>> ice_fltr_info *fi)
>> * packets to the internal switch that will be dropped.
>> */
>> if (fi->lkup_type != ICE_SW_LKUP_VLAN)
>> - fi->lb_en = true;
>> + lb_en = true;
>>
>> /* Set lan_en to TRUE if
>> * 1. The switch is a VEB AND
>> @@ -2578,14 +2579,18 @@ static void ice_fill_sw_info(struct ice_hw
>> *hw, struct ice_fltr_info *fi)
>> !is_unicast_ether_addr(fi-
>>> l_data.mac.mac_addr)) ||
>> (fi->lkup_type == ICE_SW_LKUP_MAC_VLAN &&
>> !is_unicast_ether_addr(fi-
>>> l_data.mac.mac_addr)))
>> - fi->lan_en = true;
>> + lan_en = true;
>> } else {
>> - fi->lan_en = true;
>> + lan_en = true;
>> }
>> }
>>
>> if (fi->flag & ICE_FLTR_TX_ONLY)
>> - fi->lan_en = false;
>> + lan_en = false;
>> + if (!(fi->lb_en & ICE_FLTR_INFO_LB_LAN_FORCE_MASK))
>> + fi->lb_en = lb_en;
>> + if (!(fi->lan_en & ICE_FLTR_INFO_LB_LAN_FORCE_MASK))
>> + fi->lan_en = lan_en;
> For me it looks strange.
> What type the fi->lb_en has?
> fi->lb_en declared as bool, and you assign fi->lan_en from bool.
> But you check condition by fi->lan_en & ICE_FLTR_INFO_LB_LAN_FORCE_MASK ?
I agree this can look strange. lb_en and lan_en are both u8 in
ice_switch.h:/^struct ice_fltr_info/ and we assign them from bool.
Before, even though we had the same implicit conversion bool -> u8 we
did not use either of u8s to hold anything else.
> It rases questions if fi->lan_en a bool why use fi->lan_en & ICE_FLTR_INFO_LB_LAN_FORCE_MASK then?
> And if fi->lan_en is a bitmask why not use FIELD_GET(ICE_FLTR_INFO_LB_LAN_FORCE_MASK, fi->lan_en) and
> why not something like:
>
> if (!FIELD_GET(ICE_FLTR_INFO_LB_LAN_FORCE_MASK, fi->lan_en))
> FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_MASK, &fi->lan_en, lan_en);
>
> It could preserve unrelated bits (like FORCE) and make the code resilient to future changes in bit positions?
The latter. Original intention, one of, was to avoid implying this
can be extended, because it should not: for better customization we
have "advanced" rules, and "simple" rules shouldn't try to chase them.
Instead, porting everything to "advanced" rules would be more reasonable.
I make an exception here, because cost of any other option is way higher.
That being said, I don't see any reason to not use
FIELD_{GET,PREP,MODIFY}. I will modify this accordingly across the
series.
Thanks!
>> }
>>
>> /**
next prev parent reply other threads:[~2025-11-24 10:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 16:28 [Intel-wired-lan] [PATCH iwl-next 0/8] ice: in VEB, prevent "cross-vlan" traffic Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 1/8] ice: in dvm, use outer VLAN in MAC, VLAN lookup Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 2/8] ice: allow creating mac, vlan filters along mac filters Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 3/8] ice: do not check for zero mac when creating " Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 4/8] ice: allow overriding lan_en, lb_en in switch Jakub Slepecki
2025-11-21 9:21 ` Loktionov, Aleksandr
2025-11-24 10:20 ` Jakub Slepecki [this message]
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 5/8] ice: update mac, vlan rules when toggling between VEB and VEPA Jakub Slepecki
2025-11-21 8:54 ` Loktionov, Aleksandr
2025-11-21 9:25 ` Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 6/8] ice: add functions to query for vsi's pvids Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 7/8] ice: add mac vlan to filter API Jakub Slepecki
2025-11-20 16:28 ` [Intel-wired-lan] [PATCH iwl-next 8/8] ice: in VEB, prevent "cross-vlan" traffic from hitting loopback Jakub Slepecki
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=ef41487b-ecfb-4b25-83a2-c97d6aa3c813@intel.com \
--to=jakub.slepecki@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.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;
as well as URLs for NNTP newsgroup(s).