Re: [net-next-2.6, v4 1/3] ethtool: Introduce n-tuple filter programming support

[Patrick McHardy <kaber@trash.net>]

Peter P Waskiewicz Jr wrote:
> On Wed, 2010-02-10 at 22:16 -0800, Patrick McHardy wrote:
>>> I agree that an underlying driver will have much of the same in terms of 
>>> what it generates, but it will not be restricted to how it stores the 
>>> items.  In other words, if ixgbe wanted to retrieve all 8192 filters, we 
>>> could avoid the caching altogether, and pull directly from HW when the 
>>> call is made from ethtool.  One way or another, there's going to be a big 
>>> amount of copied data from kernel space to user space.  This was the 
>>> approach I thougt would be the most useful without defining a kernel to 
>>> userspace chain of flow spec structs.
>> My main concern is that its hard for userspace to do anything with
>> this data except print it. By using a binary representation the
>> kernel code should get simpler and less prone to potential
>> inconsistencies within drivers and make it more useful to userspace
>> at the same time.
> 
> It would be easier to change ethtool in userspace to reformat data.

I'm thinking more about other potential users of this interface.

> However, some drivers/hardware may represent data in a different way for
> their filters, much like the ethtool stats (ethtool -S).  I see this as
> a hardware-specific thing, so letting the kernel provide the strings is
> the most flexible, since it's the most representative of the hardware.

I think there's a difference between stats and filters. In case of
filters, userspace already needs to know the representation without
knowing the specific driver in order to send them to the kernel, so
it needs to use a common representation unless I'm missing something.

But fair enough, I just wanted to state my concerns, which might of
course be wrong.