From: Dimitris Michailidis <dm@chelsio.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: davem@davemloft.net, jeffrey.t.kirsher@intel.com,
bhutchings@solarflare.com, netdev@vger.kernel.org
Subject: Re: [ethtool PATCH 4/4] v5 Add RX packet classification interface
Date: Tue, 03 May 2011 16:23:39 -0700 [thread overview]
Message-ID: <4DC08E7B.7070906@chelsio.com> (raw)
In-Reply-To: <20110503161226.29251.40838.stgit@gitlad.jf.intel.com>
On 05/03/2011 09:12 AM, Alexander Duyck wrote:
[...]
> +static int rmgr_add(struct ethtool_rx_flow_spec *fsp)
> +{
> + __u32 loc = fsp->location;
Unneeded assignment. Couple lines later you assign a new value to loc.
> + __u32 slot_num;
> +
> + /* start at the end of the list since it is lowest priority */
> + loc = rmgr.size - 1;
> +
> + /* locate the first slot a rule can be placed in */
> + slot_num = loc / BITS_PER_LONG;
> +
> + /*
> + * Avoid testing individual bits by inverting the word and checking
> + * to see if any bits are left set, if so there are empty spots. By
> + * moving 1 + loc % BITS_PER_LONG we align ourselves to the last bit
> + * in the previous word.
> + *
> + * If loc rolls over it should be greater than or equal to rmgr.size
> + * and as such we know we have reached the end of the list.
> + */
> + if (!~(rmgr.slot[slot_num] | (~1UL << rmgr.size % BITS_PER_LONG))) {
> + loc -= 1 + (loc % BITS_PER_LONG);
> + slot_num--;
> + }
> +
> + /*
> + * Now that we are aligned with the last bit in each long we can just
> + * go though and eliminate all the longs with no free bits
> + */
> + while (loc < rmgr.size && !~(rmgr.slot[slot_num])) {
> + loc -= BITS_PER_LONG;
> + slot_num--;
> + }
> +
> + /*
> + * If we still are inside the range, test individual bits as one is
> + * likely available for our use.
> + */
> + while (loc < rmgr.size && test_bit(loc, rmgr.slot))
> + loc--;
> +
> + /* location found, insert rule */
> + if (loc < rmgr.size) {
> + fsp->location = loc;
> + return rmgr_ins(loc);
> + }
> +
> + /* No space to add this rule */
> + fprintf(stderr, "rmgr: Cannot find appropriate slot to insert rule\n");
> +
> + return -1;
> +}
[...]
> +int rxclass_rule_ins(int fd, struct ifreq *ifr,
> + struct ethtool_rx_flow_spec *fsp)
> +{
> + struct ethtool_rxnfc nfccmd;
> + __u32 loc = fsp->location;
> + int err;
> +
> + /*
> + * if location is unspecified pull rules from device
> + * and allocate a free rule for our use
> + */
> + if (loc == RX_CLS_LOC_UNSPEC) {
> + /* init table of available rules */
> + err = rmgr_init(fd, ifr);
> + if (err < 0)
> + return err;
> +
> + /* verify rule location */
> + err = rmgr_add(fsp);
> + if (err < 0)
> + return err;
> +
> + /* cleanup table and free resources */
> + rmgr_cleanup();
> + }
This logic where ethtool tries to select a filter slot when a user provides
RX_CLS_LOC_UNSPEC does not work in general. It assumes that all slots are
equal and a new filter can go into any available slot. But a device may have
restrictions on where a filter may go that ethtool doesn't know. I
mentioned during a previous review that for cxgb4 some filters require a
slot number that is a multiple of 4. There are some other constraints as
well depending on the type of filter being added. For such a device ethtool
doesn't know enough to handle RX_CLS_LOC_UNSPEC correctly.
I think RX_CLS_LOC_UNSPEC should be passed to the driver, where there is
enough knowledge to pick an appropriate slot. So I'd remove the
if (loc == RX_CLS_LOC_UNSPEC)
block above, let the driver pick a slot, and then pass the selected location
back for ethtool to report.
next prev parent reply other threads:[~2011-05-03 23:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 16:12 [ethtool PATCH 0/4] Add support for network flow classifier Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 1/4] ethtool: remove strings based approach for displaying n-tuple Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 2/4] Cleanup defines and header includes to address several issues Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 3/4] Add support for __be64 and bitops, centralize several needed macros Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 4/4] v5 Add RX packet classification interface Alexander Duyck
2011-05-03 23:23 ` Dimitris Michailidis [this message]
2011-05-03 23:34 ` Ben Hutchings
2011-05-04 0:29 ` Alexander Duyck
2011-05-04 1:35 ` Dimitris Michailidis
2011-05-04 3:10 ` Alexander Duyck
2011-05-04 17:09 ` Dimitris Michailidis
2011-05-04 17:24 ` Ben Hutchings
2011-05-04 17:33 ` Dimitris Michailidis
2011-05-04 17:41 ` Alexander Duyck
2011-05-04 18:05 ` Ben Hutchings
2011-05-04 18:21 ` Alexander Duyck
2011-05-04 18:45 ` Ben Hutchings
2011-05-04 21:07 ` Alexander Duyck
2011-05-04 21:54 ` Ben Hutchings
2011-05-04 19:06 ` Dimitris Michailidis
2011-05-04 18:18 ` Dimitris Michailidis
2011-05-04 18:35 ` Alexander Duyck
2011-05-04 18:50 ` Dimitris Michailidis
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=4DC08E7B.7070906@chelsio.com \
--to=dm@chelsio.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
/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.