From: Jeff Garzik <jeff@garzik•org>
To: Ben Hutchings <bhutchings@solarflare•com>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel•com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel•com>
Cc: davem@davemloft•net,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"gospo@redhat•com" <gospo@redhat•com>
Subject: Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
Date: Fri, 26 Feb 2010 16:05:19 -0500 [thread overview]
Message-ID: <4B88378F.9040104@garzik.org> (raw)
In-Reply-To: <1267214397.2098.17.camel@achroite.uk.solarflarecom.com>
On 02/26/2010 02:59 PM, Ben Hutchings wrote:
> On Thu, 2010-02-25 at 21:26 -0500, Jeff Garzik wrote:
>> On 02/25/2010 08:49 PM, Waskiewicz Jr, Peter P wrote:
> [...]
>>> This will require a small kernel change. Will something like this be
>>> pulled in at this point, given that 2.6.33 just released?
>>
>> The n-tuple stuff is not in 2.6.33's ethtool interface, so it hasn't
>> actually made it into a released kernel at this point.
>>
>> It seems reasonable for 2.6.34 to either add ETHTOOL_GSTRINGS_COUNT or
>> update drvinfo. Even if net-next has already been pulled into
>> post-2.6.33 merge window, that would IMO qualify as a reasonable
>> interface bugfix to get upstream. The ethtool n-tuple ABI is not locked
>> into stone until 2.6.34 is released by Linus.
>
> Given that, I would really like to see the tuple strings replaced with
> binary structures. Setting them in binary format and retrieving them in
> text format is inelegant. Also we should not assume that ethtool is the
> only user of the ethtool API. If someone wanted to write a GUI to
> manage the filter tuples, or a tool that would programmatically
> reconfigure filters, they would have to parse the strings.
>
> Even the lookup of number of strings seems to be completely
> misconceived. It's delegated to the driver thus:
>
> ret = ops->get_sset_count(dev, gstrings.string_set);
> if (ret< 0)
> return ret;
>
> What if gstrings.string_set != ETH_SS_NTUPLE_FILTERS? Why is that even
> a parameter to the operation?
>
> Further, each filter can be formatted as multiple strings. So is the
> driver supposed to know how many strings the ethtool core might
> generate?
Speaking _generally_, not specifically about n-tuple filters, text
strings are much more flexible across varied types of hardware. For
example, the "private flags" ethtool interface is intended to be used as
a generic means for a driver to export a set of hardware-specific
boolean knobs.
For example, e1000e's SmartPowerDownEnable need not be a module-wide
parameter applying to all e1000e devices in the system. ethtool's
private-flags interface could enable per-net_device runtime setting of
this Intel-specific feature, simply by exporting a string
"SmartPowerDownEnable" as a private flag.
Thus, text strings isolate the problem of hardware-specific settings,
features and structures entirely in the kernel driver itself.
Getting back to n-tuple filters, the question becomes: how
hardware-specific are the filter formats?
Using binary structures is generally more efficient... but efficiency
is not really a primary goal. Working across a broad spectrum of
hardware, future-proof-edness, is more important. Binary structures may
lock ethtool users into a very specific filter specification -- one that
might not be as easily applicable to other vendors' hardware, or even
future hardware from the same vendor.
procfs and sysfs exist in their current, ASCII-friendly form in part
because Linus has often observed that text strings are often easier and
more resilient kernel<->userspace interfaces than binary interfaces.
All that said, I cannot argue that there are elements of the current
Intel implementation that are quite inelegant, and binary structures may
simply be easier.
Like everything else in life, it's a balance... ;-)
Jeff
next prev parent reply other threads:[~2010-02-26 21:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 7:51 [ethtool PATCH] ethtool: Support n-tuple filter programming Jeff Kirsher
2010-02-25 3:41 ` Jeff Garzik
2010-02-25 7:04 ` Waskiewicz Jr, Peter P
2010-02-25 10:26 ` Jeff Garzik
2010-02-26 1:49 ` Waskiewicz Jr, Peter P
2010-02-26 2:26 ` Jeff Garzik
2010-02-26 5:53 ` David Miller
2010-02-26 6:09 ` Peter P Waskiewicz Jr
2010-02-26 19:59 ` Ben Hutchings
2010-02-26 21:05 ` Jeff Garzik [this message]
2010-06-21 19:57 ` Ben Hutchings
2010-06-21 20:31 ` Peter P Waskiewicz Jr
2010-06-21 20:49 ` Mitchell Erblich
2010-06-22 6:42 ` Peter P Waskiewicz Jr
2010-06-22 11:45 ` Ben Hutchings
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=4B88378F.9040104@garzik.org \
--to=jeff@garzik$(echo .)org \
--cc=bhutchings@solarflare$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=gospo@redhat$(echo .)com \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=peter.p.waskiewicz.jr@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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