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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 11 Feb 2010 08:53:11 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: Re: [net-next-2.6,	v4 1/3] ethtool: Introduce n-tuple filter programming
 support

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.
--
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