[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DC09DE0.8070102@intel.com>
Date: Tue, 03 May 2011 17:29:20 -0700
From: Alexander Duyck <alexander.h.duyck@...el.com>
To: Ben Hutchings <bhutchings@...arflare.com>
CC: Dimitris Michailidis <dm@...lsio.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [ethtool PATCH 4/4] v5 Add RX packet classification interface
On 5/3/2011 4:34 PM, Ben Hutchings wrote:
> On Tue, 2011-05-03 at 16:23 -0700, Dimitris Michailidis wrote:
>> On 05/03/2011 09:12 AM, Alexander Duyck wrote:
> [...]
>>> +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 agree. And if filter lookup is largely hash-based (as it is in
> Solarflare hardware) the user will also find it very difficult to
> specify the right location!
The thing to keep in mind is that the index doesn't have to be a
hardware index. In ixgbe we have a field in the hardware which is meant
to just be a unique software index and that is what I am using as the
location field for our filters. All the location information in the
rules really provides is a logical way of tracking rules. It doesn't
necessarily have to represent the physical location of the rule in hardware.
>> 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.
>
> But first we have to specify this in the ethtool API. So please propose
> a patch to ethtool.h.
>
> Ben.
The other thing to keep in mind with this is that it doesn't lock you
into the network flow classifier configuration. If you want to be able
to specify a rule without having any location information included there
is always the option of ntuple which accepts almost all the same fields
but doesn't include any specific location information.
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists