netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>
To: "alexander.duyck@gmail.com" <alexander.duyck@gmail.com>
Cc: "Cao, Chinh T" <chinh.t.cao@intel.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"Behera, BrijeshX" <brijeshx.behera@intel.com>,
	"Valiquette, Real" <real.valiquette@intel.com>,
	"sassmann@redhat.com" <sassmann@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [net-next v3 05/15] ice: create flow profile
Date: Sat, 21 Nov 2020 00:42:35 +0000	[thread overview]
Message-ID: <fd0fc6f95f4c107d1aed18bf58239fda91879b26.camel@intel.com> (raw)
In-Reply-To: <CAKgT0UeQ5q2M-uiR0-1G=30syPiO8S5OFHvDuN1XtQg5700hCg@mail.gmail.com>

On Fri, 2020-11-13 at 15:56 -0800, Alexander Duyck wrote:
> On Fri, Nov 13, 2020 at 1:46 PM Tony Nguyen <
> anthony.l.nguyen@intel.com> wrote:
> > 
> > From: Real Valiquette <real.valiquette@intel.com>
> > 
> > Implement the initial steps for creating an ACL filter to support
> > ntuple
> > masks. Create a flow profile based on a given mask rule and program
> > it to
> > the hardware. Though the profile is written to hardware, no actions
> > are
> > associated with the profile yet.
> > 
> > Co-developed-by: Chinh Cao <chinh.t.cao@intel.com>
> > Signed-off-by: Chinh Cao <chinh.t.cao@intel.com>
> > Signed-off-by: Real Valiquette <real.valiquette@intel.com>
> > Co-developed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > Tested-by: Brijesh Behera <brijeshx.behera@intel.com>
> 
> So I see two big issues with the patch.
> 
> First it looks like there is an anti-pattern of defensive NULL
> pointer
> checks throughout. Those can probably all go since all of the callers
> either use the pointer, or verify it is non-NULL before calling the
> function in question.

I'm removing those checks that you pointed out and some others as well.

> 
> In addition the mask handling doens't look right to me. It is calling
> out a partial mask as being the only time you need an ACL and I would
> think it is any time you don't have a full mask for all
> ports/addresses since a flow director rule normally pulls in the full
> 4 tuple based on ice_ntuple_set_input_set() .

Commented below as well.

<snip>

> > +/**
> > + * ice_is_acl_filter - Checks if it's a FD or ACL filter
> > + * @fsp: pointer to ethtool Rx flow specification
> > + *
> > + * If any field of the provided filter is using a partial mask
> > then this is
> > + * an ACL filter.
> > + *
> 
> I'm not sure this logic is correct. Can the flow director rules
> handle
> a field that is removed? Last I knew it couldn't. If that is the case
> you should be using ACL for any case in which a full mask is not
> provided. So in your tests below you could probably drop the check
> for
> zero as I don't think that is a valid case in which flow director
> would work.
> 

I'm not sure what you meant by a field that is removed, but Flow
Director can handle reduced input sets. Flow Director is able to handle
0 mask, full mask, and less than 4 tuples. ACL is needed/used only when
a partial mask rule is requested.


> > + * Returns true if ACL filter otherwise false.
> > + */
> > +static bool ice_is_acl_filter(struct ethtool_rx_flow_spec *fsp)
> > +{
> > +       struct ethtool_tcpip4_spec *tcp_ip4_spec;
> > +       struct ethtool_usrip4_spec *usr_ip4_spec;
> > +
> > +       switch (fsp->flow_type & ~FLOW_EXT) {
> > +       case TCP_V4_FLOW:
> > +       case UDP_V4_FLOW:
> > +       case SCTP_V4_FLOW:
> > +               tcp_ip4_spec = &fsp->m_u.tcp_ip4_spec;
> > +
> > +               /* IP source address */
> > +               if (tcp_ip4_spec->ip4src &&
> > +                   tcp_ip4_spec->ip4src != htonl(0xFFFFFFFF))
> > +                       return true;
> > +
> > +               /* IP destination address */
> > +               if (tcp_ip4_spec->ip4dst &&
> > +                   tcp_ip4_spec->ip4dst != htonl(0xFFFFFFFF))
> > +                       return true;
> > +
> 
> Instead of testing this up here you could just skip the break and
> fall
> through since the source and destination IP addresses occupy the same
> spots on usr_ip4_spec and tcp_ip4_spec. You could probably also just
> use tcp_ip4_spec for the entire test.

Will make this change.

Thanks,
Tony

  reply	other threads:[~2020-11-21  0:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 21:44 [net-next v3 00/15][pull request] 100GbE Intel Wired LAN Driver Updates 2020-11-13 Tony Nguyen
2020-11-13 21:44 ` [net-next v3 01/15] ice: cleanup stack hog Tony Nguyen
2020-11-13 21:44 ` [net-next v3 02/15] ice: rename shared Flow Director functions Tony Nguyen
2020-11-13 21:44 ` [net-next v3 03/15] ice: initialize ACL table Tony Nguyen
2020-11-13 21:44 ` [net-next v3 04/15] ice: initialize ACL scenario Tony Nguyen
2020-11-13 21:44 ` [net-next v3 05/15] ice: create flow profile Tony Nguyen
2020-11-13 23:56   ` Alexander Duyck
2020-11-21  0:42     ` Nguyen, Anthony L [this message]
2020-11-21  1:49       ` Alexander Duyck
2020-11-23 23:21         ` Jesse Brandeburg
2020-11-24  1:11           ` Alexander Duyck
2020-12-08 16:58             ` Nguyen, Anthony L
2020-12-08 19:00               ` Alexander Duyck
2020-12-08 22:01                 ` Nguyen, Anthony L
2020-12-08 22:22                   ` Alexander Duyck
2020-12-09 18:23                     ` Nguyen, Anthony L
2020-11-13 21:44 ` [net-next v3 06/15] ice: create ACL entry Tony Nguyen
2020-11-13 21:44 ` [net-next v3 07/15] ice: program " Tony Nguyen
2020-11-13 21:44 ` [net-next v3 08/15] ice: don't always return an error for Get PHY Abilities AQ command Tony Nguyen
2020-11-14  1:25   ` Alexander Duyck
2020-11-21  0:43     ` Nguyen, Anthony L
2020-11-13 21:44 ` [net-next v3 09/15] ice: Enable Support for FW Override (E82X) Tony Nguyen
2020-11-13 21:44 ` [net-next v3 10/15] ice: Remove gate to OROM init Tony Nguyen
2020-11-13 21:44 ` [net-next v3 11/15] ice: Remove vlan_ena from vsi structure Tony Nguyen
2020-11-13 21:44 ` [net-next v3 12/15] ice: cleanup misleading comment Tony Nguyen
2020-11-13 21:44 ` [net-next v3 13/15] ice: silence static analysis warning Tony Nguyen
2020-11-13 21:44 ` [net-next v3 14/15] ice: join format strings to same line as ice_debug Tony Nguyen
2020-11-13 21:44 ` [net-next v3 15/15] ice: Add space to unknown speed Tony Nguyen

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=fd0fc6f95f4c107d1aed18bf58239fda91879b26.camel@intel.com \
    --to=anthony.l.nguyen@intel.com \
    --cc=alexander.duyck@gmail.com \
    --cc=brijeshx.behera@intel.com \
    --cc=chinh.t.cao@intel.com \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=real.valiquette@intel.com \
    --cc=sassmann@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 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).