netdev - Re: [RFC] ethtool: Support for driver private ioctl's

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]

Message-ID: <d1911f61-1d3b-e37d-32a4-d5cd221ca1cf@synopsys.com>
Date:   Tue, 24 Apr 2018 10:37:58 +0100
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Jose Abreu <Jose.Abreu@...opsys.com>,
        David Miller <davem@...hat.com>,
        Jakub Jelinek <jj@...ra.linux.cz>,
        Jeff Garzik <jgarzik@...ox.com>, Tim Hockin <thockin@....com>,
        Eli Kupermann <eli.kupermann@...el.com>,
        Chris Leech <christopher.leech@...el.com>,
        Scott Feldman <scott.feldman@...el.com>,
        "Ben Hutchings" <ben@...adent.org.uk>
CC:     <netdev@...r.kernel.org>, Joao Pinto <Joao.Pinto@...opsys.com>
Subject: Re: [RFC] ethtool: Support for driver private ioctl's

Hi Florian,

On 07-04-2018 20:58, Florian Fainelli wrote:
>
> On 04/06/2018 06:51 AM, Jose Abreu wrote:
>> Hi Florian,
>>
>> On 05-04-2018 16:50, Florian Fainelli wrote:
>>> On 04/05/2018 03:47 AM, Jose Abreu wrote:
>>>> Hi All,
>>>>
>>>> I would like to know your opinion regarding adding support for
>>>> driver private ioctl's in ethtool.
>>>>
>>>> Background: Synopsys Ethernet IP's have a certain number of
>>>> features which can be reconfigured at runtime. Giving you two
>>>> examples: One of the most recent one is the safety features,
>>>> which can be enabled/disabled and forced at runtime. Another one
>>>> is a Flexible RX Parser which can route specific packets to
>>>> specific RX DMA channels. Given that these are features specific
>>>> to our IP's it would not be useful to add an uniform API for this
>>>> because the users would only be one or two drivers ...
>>> Parsing of packets and directing the matched packets to specific
>>> queues/channels can be done through ethtool rxnfc API, tc/cls_flower as
>>> well, so you should really check whether those APIs don't already allow
>>> you to do what you want.
>> Hmm, but in our case this is directly done by HW, we just have to
>> program a kind of a table which will route automatically the
>> packets. Does this API support this?
> I was sort of expecting you to look at the ethtool rxnfc API to see if
> it is suitable given your hardware, but if this is indeed a table
> programming, then yes, this is what it is designed for. You might want
> to consider using the newer, albeit more complex tc/cls_flower if that
> works for your use case.
>

I took a quick look at rxrnfc API and it doesn't seem to match
entirely my requirements.

The feature I want to introduce is called Flexible RX Parser and
will let me route specific packets to specific DMA channels
number. This is different from rxrnfc API because, and I far as I
understand, the API was designed to add rules to packet types
whilst in my case I can add a rule to *any* of the packet content
(within the first 256 bytes of packet, at max). So technically I
can route packets based on destination/ source mac address,
packet type, lenght, protocol, source/destination IP , ....

So, I guess cls_flower it will be ... I'm slowing looking at some
code and docs but it would be great if you could pin point me to
some HW that has similar behavior ?

Thanks and Best Regards,
Jose Miguel Abreu