netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Santwona.Behera@Sun.COM
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, gkernel-commit@lists.sourceforge.net,
	Matheos Worku <Matheos.Worku@Sun.COM>
Subject: Re: Interface proposal for rx classification using ethtool
Date: Fri, 17 Oct 2008 11:16:19 -0700	[thread overview]
Message-ID: <48F8D673.5070101@Sun.COM> (raw)
In-Reply-To: <20081015.161915.153810861.davem@davemloft.net>



On 10/15/08 16:19, David Miller wrote:
> From: Santwona.Behera@Sun.COM
> Date: Mon, 29 Sep 2008 10:28:07 -0700
> 
>> 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.
> 
> This looks mostly fine to me, thanks for working on this.
> 
> I do have one question though.
> 
> At least to some extent the user will have to have a way to
> figure out that multiple interfaces correspond to one instance
> of the TCAM.  Because this determines sharing and other
> aspects, right?

That will not be the case as the driver will partition the TCAM on a per
interface basis. So the entries for each interface will be independent
of each other. This has been done to make the ethtool interface
independent of the TCAM implementation, i.e., if there are multiple
TCAMs in any future revs of the hardware or in any other hardware, the
per port API should work.

> 
> How it seems to work in your description is that the user operates on
> (for example) eth0 and eth1 as if they were independant objects, but
> if the TCAM fills up that will be seen equally by operations on both
> interfaces.

Each partition in the TCAM will fill up independently for each
interface.

> 
> But, to be honest this is a minor detail.
> 
> They may also be value in allowing TCAM entries to be locked by the
> kernel and thus be unmodifyable by the user.

That will be the case. All updates will be done by the driver to
implement the partitioning.

> 
> For example, in NIU, those special workaround entries we add to handle
> IP fragments would be a candidate for this.

That is right. In fact these entries will be put in by the driver and
will not be exported to the user. The partitioning for each port will
start in the region after these entries.

--santwona

  reply	other threads:[~2008-10-17 18:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-29 17:28 Interface proposal for rx classification using ethtool Santwona.Behera
2008-10-15 23:19 ` David Miller
2008-10-17 18:16   ` Santwona.Behera [this message]
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=48F8D673.5070101@Sun.COM \
    --to=santwona.behera@sun.com \
    --cc=Matheos.Worku@Sun.COM \
    --cc=davem@davemloft.net \
    --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).