[dpdk-dev] Query on Filtering Support in DPDK

[dpdk-dev] Query on Filtering Support in DPDK

[Rahul Lakkireddy]

Hi,

We are working towards adding h/w based filtering support in cxgbe PMD.

Chelsio T5 supports carrying out filtering in hardware which supports 3
actions to carry out on a packet which hit a filter viz.

1. Action Pass - Packets hitting a filter rule can be directed to a
   particular RXQ.

2. Action Drop - Packets hitting a filter rule are dropped in h/w.

3. Action Switch - Packets hitting a filter rule can be switched in h/w
   from one port to another, without involvement of host.  Also, the
   action Switch also supports rewrite of src-mac/dst-mac headers as
   well as rewrite of vlan headers.  It also supports rewrite of IP
   headers and thereby, supports NAT (Network Address Translation)
   in h/w.

Also, each filter rule can optionally support specifying a mask value
i.e. it's possible to create a filter rule for an entire subnet of IP
addresses or a range of tcp/udp ports, etc.

We went through the existing filtering support (ethertype_filter,
syn_filter, ntuple_filter, flow_director) and have some questions on how
to accommodate the various h/w filtering features supported by Chelsio T5
by extending DPDK filtering support.

Some of the features that we would like to accommodate in DPDK filtering
are:

1. Add a new action 'switch' that will:
   * Allow re-direction to different ports in hardware.

   Also, for such a rule, additionally support below:

   * Allow source mac/destination mac and vlan header re-writing to be
     done by the hardware.

   * Allow re-write of TCP/IP headers to perform NAT in hardware.

2. Add ability to mask individual fields at a particular layer for each
   filter in flow_director. For example, mask all ip packets coming from
   a particular subnet mask and particular range of l4 ports for each
   filter rule.

We would like to get some suggestions on how to proceed with adding the
above features.

Thanks,
Rahul

Re: [dpdk-dev] Query on Filtering Support in DPDK

[Thomas Monjalon]

Hi,

2015-11-30 18:19, Rahul Lakkireddy:
> 1. Add a new action 'switch' that will:
>    * Allow re-direction to different ports in hardware.
> 
>    Also, for such a rule, additionally support below:
> 
>    * Allow source mac/destination mac and vlan header re-writing to be
>      done by the hardware.
> 
>    * Allow re-write of TCP/IP headers to perform NAT in hardware.
> 
> 2. Add ability to mask individual fields at a particular layer for each
>    filter in flow_director. For example, mask all ip packets coming from
>    a particular subnet mask and particular range of l4 ports for each
>    filter rule.
> 
> We would like to get some suggestions on how to proceed with adding the
> above features.

You need to identify which API must change and what will be the ABI changes.
Then please send a deprecation notice before December 11 in order to be part
of the 2.2 release notes.

If you have some RFC patches to send (at least the API changes), it would be
a good discussion start.

Thanks

Re: [dpdk-dev] Query on Filtering Support in DPDK

[Rahul Lakkireddy]

Hi Thomas,

On Monday, November 11/30/15, 2015 at 05:43:18 -0800, Thomas Monjalon wrote:
> Hi,
> 
> 2015-11-30 18:19, Rahul Lakkireddy:
> > 1. Add a new action 'switch' that will:
> >    * Allow re-direction to different ports in hardware.
> > 
> >    Also, for such a rule, additionally support below:
> > 
> >    * Allow source mac/destination mac and vlan header re-writing to be
> >      done by the hardware.
> > 
> >    * Allow re-write of TCP/IP headers to perform NAT in hardware.
> > 
> > 2. Add ability to mask individual fields at a particular layer for each
> >    filter in flow_director. For example, mask all ip packets coming from
> >    a particular subnet mask and particular range of l4 ports for each
> >    filter rule.
> > 
> > We would like to get some suggestions on how to proceed with adding the
> > above features.
> 
> You need to identify which API must change and what will be the ABI changes.
> Then please send a deprecation notice before December 11 in order to be part
> of the 2.2 release notes.

I am currently identifying the various API changes to support this and
also the ABI changes if any.

> 
> If you have some RFC patches to send (at least the API changes), it would be
> a good discussion start.

I will try to post some RFC patches in 3-4 days time to get more
inputs/reviews on the approach.

Thanks,
Rahul.