Interface proposal for rx classification using ethtool

Interface proposal for rx classification using ethtool

[Santwona.Behera]

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

Re: Interface proposal for rx classification using ethtool

[David Miller]

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?

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.

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.

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

Re: Interface proposal for rx classification using ethtool

[Santwona.Behera]

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

Re: Interface proposal for rx classification using ethtool

[Kumar Gala]

On Sep 29, 2008, at 12:28 PM, Santwona.Behera@Sun.COM wrote:

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

What's the state of patches for this work?

- k

Re: Interface proposal for rx classification using ethtool

[Santwona.Behera]

> 
> What's the state of patches for this work?
> 
> - k

I am working on it. The goal is to submit the patches by middle
of November.

--santwona

> -- 
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html