From: Leon Romanovsky <leon@kernel.org>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: Ahmed Zaki <ahmed.zaki@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, netdev@vger.kernel.org,
Arpana Arland <arpanax.arland@intel.com>
Subject: Re: [PATCH net 1/1] ice: identify aRFS flows using L3/L4 dissector info
Date: Fri, 14 Apr 2023 11:54:05 +0300 [thread overview]
Message-ID: <20230414085405.GZ17993@unreal> (raw)
In-Reply-To: <09ec7b55-5ec9-2abc-dbb8-cdb7e0b0c6a8@intel.com>
On Thu, Apr 13, 2023 at 10:27:56AM -0700, Jacob Keller wrote:
>
>
> On 4/10/2023 11:54 AM, Ahmed Zaki wrote:
> >
> > On 2023-04-09 04:45, Leon Romanovsky wrote:
> >> On Fri, Apr 07, 2023 at 02:08:20PM -0700, Tony Nguyen wrote:
> >>> From: Ahmed Zaki <ahmed.zaki@intel.com>
> >>>
> >>> The flow ID passed to ice_rx_flow_steer() is computed like this:
> >>>
> >>> flow_id = skb_get_hash(skb) & flow_table->mask;
> >>>
> >>> With smaller aRFS tables (for example, size 256) and higher number of
> >>> flows, there is a good chance of flow ID collisions where two or more
> >>> different flows are using the same flow ID. This results in the aRFS
> >>> destination queue constantly changing for all flows sharing that ID.
> >>>
> >>> Use the full L3/L4 flow dissector info to identify the steered flow
> >>> instead of the passed flow ID.
> >>>
> >>> Fixes: 28bf26724fdb ("ice: Implement aRFS")
> >>> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
> >>> Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
> >>> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> >>> ---
> >>> drivers/net/ethernet/intel/ice/ice_arfs.c | 44 +++++++++++++++++++++--
> >>> 1 file changed, 41 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/net/ethernet/intel/ice/ice_arfs.c b/drivers/net/ethernet/intel/ice/ice_arfs.c
> >>> index fba178e07600..d7ae64d21e01 100644
> >>> --- a/drivers/net/ethernet/intel/ice/ice_arfs.c
> >>> +++ b/drivers/net/ethernet/intel/ice/ice_arfs.c
> >>> @@ -345,6 +345,44 @@ ice_arfs_build_entry(struct ice_vsi *vsi, const struct flow_keys *fk,
> >>> return arfs_entry;
> >>> }
> >>>
> >>> +/**
> >>> + * ice_arfs_cmp - compare flow to a saved ARFS entry's filter info
> >>> + * @fltr_info: filter info of the saved ARFS entry
> >>> + * @fk: flow dissector keys
> >>> + *
> >>> + * Caller must hold arfs_lock if @fltr_info belongs to arfs_fltr_list
> >>> + */
> >>> +static bool
> >>> +ice_arfs_cmp(struct ice_fdir_fltr *fltr_info, const struct flow_keys *fk)
> >>> +{
> >>> + bool is_ipv4;
> >>> +
> >>> + if (!fltr_info || !fk)
> >>> + return false;
> >>> +
> >>> + is_ipv4 = (fltr_info->flow_type == ICE_FLTR_PTYPE_NONF_IPV4_UDP ||
> >>> + fltr_info->flow_type == ICE_FLTR_PTYPE_NONF_IPV4_TCP);
> >>> +
> >>> + if (fk->basic.n_proto == htons(ETH_P_IP) && is_ipv4)
> >>> + return (fltr_info->ip.v4.proto == fk->basic.ip_proto &&
> >>> + fltr_info->ip.v4.src_port == fk->ports.src &&
> >>> + fltr_info->ip.v4.dst_port == fk->ports.dst &&
> >>> + fltr_info->ip.v4.src_ip == fk->addrs.v4addrs.src &&
> >>> + fltr_info->ip.v4.dst_ip == fk->addrs.v4addrs.dst);
> >>> + else if (fk->basic.n_proto == htons(ETH_P_IPV6) && !is_ipv4)
> >>> + return (fltr_info->ip.v6.proto == fk->basic.ip_proto &&
> >>> + fltr_info->ip.v6.src_port == fk->ports.src &&
> >>> + fltr_info->ip.v6.dst_port == fk->ports.dst &&
> >>> + !memcmp(&fltr_info->ip.v6.src_ip,
> >>> + &fk->addrs.v6addrs.src,
> >>> + sizeof(struct in6_addr)) &&
> >>> + !memcmp(&fltr_info->ip.v6.dst_ip,
> >>> + &fk->addrs.v6addrs.dst,
> >>> + sizeof(struct in6_addr)));
> >> I'm confident that you can write this function more clear with
> >> comparisons in one "return ..." instruction.
> >>>> Thanks
> >
> > Do you mean remove the "if condition"? how?
> >
> > I wrote it this way to match how I'd think:
> >
> > If (IPv4 and V4 flows), test IPv4 flow keys, else if (IPv6 and V6
> > flows), test IPv6 keys, else false.
> >
>
> You can use a || chain, something like:
>
> return (is_ipv4 && (<check ipv4 fields)) || (!is_ipv4 && (<check ip6
> fields>)
>
> There might be other ways to simplify the conditional. You could
> possibly combine the n_proto check with the is_ipv4 check above as well.
Another possible option is to use variable to store intermediate result.
Thanks
>
>
> > I m not sure how can I make it more clearer.
> >
> > Thanks.
> >
next prev parent reply other threads:[~2023-04-14 8:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 21:08 [PATCH net 1/1] ice: identify aRFS flows using L3/L4 dissector info Tony Nguyen
2023-04-09 10:45 ` Leon Romanovsky
2023-04-10 18:54 ` Ahmed Zaki
2023-04-13 17:27 ` Jacob Keller
2023-04-14 8:54 ` Leon Romanovsky [this message]
2023-04-14 16:07 ` Alexander Lobakin
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=20230414085405.GZ17993@unreal \
--to=leon@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=arpanax.arland@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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.