[dpdk-dev] Query on Filtering Support in DPDK
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.
[dpdk-dev] Query on Filtering Support in DPDK
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
[dpdk-dev] Query on Filtering Support in DPDK
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
