All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jose Abreu <Jose.Abreu@synopsys.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	David Miller <davem@redhat.com>,
	Jakub Jelinek <jj@ultra.linux.cz>,
	Jeff Garzik <jgarzik@pobox.com>, Tim Hockin <thockin@sun.com>,
	Eli Kupermann <eli.kupermann@intel.com>,
	Chris Leech <christopher.leech@intel.com>,
	Scott Feldman <scott.feldman@intel.com>,
	"Ben Hutchings" <ben@decadent.org.uk>
Cc: <netdev@vger.kernel.org>, Joao Pinto <Joao.Pinto@synopsys.com>
Subject: Re: [RFC] ethtool: Support for driver private ioctl's
Date: Tue, 24 Apr 2018 10:37:58 +0100	[thread overview]
Message-ID: <d1911f61-1d3b-e37d-32a4-d5cd221ca1cf@synopsys.com> (raw)
In-Reply-To: <80a8c4b7-2f2b-4b64-3065-4384b1b1e6e2@gmail.com>

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

      reply	other threads:[~2018-04-24  9:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 10:47 [RFC] ethtool: Support for driver private ioctl's Jose Abreu
2018-04-05 15:50 ` Florian Fainelli
2018-04-06  9:07   ` Michal Kubecek
2018-04-06 13:57     ` Jose Abreu
2018-04-06 13:51   ` Jose Abreu
2018-04-06 14:47     ` Andrew Lunn
2018-04-06 14:51       ` Jose Abreu
2018-04-07 19:58     ` Florian Fainelli
2018-04-24  9:37       ` Jose Abreu [this message]

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=d1911f61-1d3b-e37d-32a4-d5cd221ca1cf@synopsys.com \
    --to=jose.abreu@synopsys.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=ben@decadent.org.uk \
    --cc=christopher.leech@intel.com \
    --cc=davem@redhat.com \
    --cc=eli.kupermann@intel.com \
    --cc=f.fainelli@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=jj@ultra.linux.cz \
    --cc=netdev@vger.kernel.org \
    --cc=scott.feldman@intel.com \
    --cc=thockin@sun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.