Re: [External] rte_flow: no ability to match on packet length?

[Tony Hart <Tony.Hart@corero.com>]

Ok I see the templates section in the programmer’s guide; that doesn’t seem to allow matching on arbitrary fields?  


Tony Hart | Chief Architect
Tony.Hart@corero.com <mailto:Tony.Hart@corero.com> 
 
 293 Boston Post Road West Suite 310, Marlborough, MA 01752 


Access Corero Network Security’s Privacy Policy here <www.corero.com/privacy>.



We are Corero Network Security plc (“Corero”), registered in England and Wales, with registered company number 02662978, registered office address Regus House Highbridge, Oxford Road, Uxbridge, Middlesex, UB8 1HR. Corero is the parent company for Corero Network Security, Inc. and Corero Network Security (UK) Ltd (a company registered in England and Wales with registered number 04047090, with the same registered office address as above) For information about how we process your data, or to manage your data preferences, click here <info.corero.com/data-preferences.html>. 



> On Mar 21, 2023, at 5:57 AM, Tony Hart <tony.hart@corero.com> wrote:
> 
> Hi Asaf,
> 
> That’s good news.  Would IPv6 payload_length also be added?
> 
> The template API sounds interesting, is it related to the Flex or Raw item matches?
> 
> Regards
> Tony
> 
> 
> 
>> On Mar 19, 2023, at 2:34 PM, Asaf Penso <asafp@nvidia.com> wrote:
>> 
>> Hello Tony,
>> 
>> Starting ConnectX-6 Dx NIC, the HW can match on range of values for different fields.
>> In general, it will be implemented as part of the rte_flow template API.
>> We plan implementing range match on ip.total_length field as part of 23.07.
>> 
>> Regards,
>> Asaf Penso
>> From: Tony Hart <Tony.Hart@corero.com>
>> Sent: Monday, March 6, 2023 1:50:11 PM
>> To: Stephen Hemminger <stephen@networkplumber.org>
>> Cc: users@dpdk.org <users@dpdk.org>
>> Subject: Re: [External] rte_flow: no ability to match on packet length?
>> 
>> Hi Stephen,
>> Thanks for the confirmation. As you say, maybe any MLX5 experts have some suggestions?
>> 
>> --tony
>> 
>> 
>> Tony Hart | Chief Architect
>> Tony.Hart@corero.com <mailto:Tony.Hart@corero.com> 
>> 
>> 293 Boston Post Road West Suite 310, Marlborough, MA 01752 
>> 
>> 
>> Access Corero Network Security’s Privacy Policy here <www.corero.com/privacy>.
>> 
>> 
>> 
>> We are Corero Network Security plc (“Corero”), registered in England and Wales, with registered company number 02662978, registered office address Regus House Highbridge, Oxford Road, Uxbridge, Middlesex, UB8 1HR. Corero is the parent company for Corero Network Security, Inc. and Corero Network Security (UK) Ltd (a company registered in England and Wales with registered number 04047090, with the same registered office address as above) For information about how we process your data, or to manage your data preferences, click here <info.corero.com/data-preferences.html>. 
>> 
>> 
>> 
>>> On Mar 5, 2023, at 3:46 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>> 
>>> On Tue, 28 Feb 2023 15:12:31 +0000
>>> Tony Hart <Tony.Hart@corero.com> wrote:
>>> 
>>>> I’m trying to use the Generic Flow API (rte_flow) to match IP packets based on their length (either L2, L3 or L4 lengths).
>>>> 
>>>> There doesn’t seem to be an item type that explicitly matches based on length (RTE_FLOW_ITEM_TYPE_x).  So I’ve tried using a mask with RTE_FLOW_ITEM_TYPE_IPV4 to match on the total_length field (and similar attempt to match on the UDP header dgram_len field) but the NIC I’m using (mlx5) returns an error (mask enables non supported bits).
>>>> 
>>>> Am I out of luck, or maybe missing something?
>>>> 
>>>> Thanks for any insights!
>>>> 
>>>> I’ve tried, DPDK: 20.11.7 and 22.11.1
>>>> 
>>>> Tony Hart | Chief Architect
>>>> Tony.Hart@corero.com <mailto:Tony.Hart@corero.com> 
>>> 
>>> Short answer: yes, you are right there is no generic length match.
>>> 
>>> Longer answer: rte_flow is an API which is meant to provide access to the underlying
>>> match features of NIC hardware. Supporting something requires that the HW/FW can do the
>>> match, and that the driver writer has added (and tested) that match.
>>> 
>>> Hopefully the MLX5 experts can help answer what is possible.
>>> 
>> 
>