netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Santwona.Behera@Sun.COM
To: netdev@vger.kernel.org, gkernel-commit@lists.sourceforge.net
Cc: Matheos Worku <Matheos.Worku@Sun.COM>,
	Santwona Behera <Santwona.Behera@Sun.COM>
Subject: Interface proposal for rx classification using ethtool
Date: Mon, 29 Sep 2008 10:28:07 -0700	[thread overview]
Message-ID: <48E11027.3060400@Sun.COM> (raw)

Here is the proposed design for implementing an interface to add, delete 
and
manage rules for RX packet classification on ethertool with niu as the 
first
target hardware. This is the second installment of network flow 
classification
support (the first one was for rx flow distribution based on hashing 
that was
added in June). Please review and send your feedback.

1. The ethertool application will have an interface to add a 
classification rule
and the target RX ring for packets that match the rule. The rules are added
on a per port basis. Each new rule that is added is represented by a 
unique ID.
This ID can be used by the user to delete the rule or query the details 
of the
rule (both interfaces provided via ethertool).

2. Here is the list of cmds/interfaces that will be added to ethertool (as
suboptions in the rx_classification option) to achieve this:

   - get the number of RX rings available to this port.
   - add a rule (flow-tuple/mask to RX ring mapping)
   - delete a rule
   - query a particular rule or all rules for this port

3. Within ethertool, there will be a manager for these rules that will 
order
the rules on a per port basis according to the policy chosen by the 
user. In
the first cut, the policy will be hardcoded as longest prefix first 
ordering.
Before adding any rules to the hardware, the rule manager will first query
the hardware for the ordering that it implements for matching, e.g., 
low-to-high
(as in case of niu TCAM). This information will be taken into account while
writing to the rule-manager and to the hardware.

4. In the niu driver, there will be a local array of the tcam_entries (for
supporting queries from ethertool).

5. There is no protection against inconsistencies between the tcam entries
and the user view of it that can arise if multiple instances of ethertool
happen to write the same rule (tcam_entry).

thanks,
--santwona

             reply	other threads:[~2008-09-29 17:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-29 17:28 Santwona.Behera [this message]
2008-10-15 23:19 ` Interface proposal for rx classification using ethtool David Miller
2008-10-17 18:16   ` Santwona.Behera
2008-10-31 10:29 ` Kumar Gala
2008-10-31 21:54   ` Santwona.Behera

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=48E11027.3060400@Sun.COM \
    --to=santwona.behera@sun.com \
    --cc=Matheos.Worku@Sun.COM \
    --cc=gkernel-commit@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).