[dpdk-users] Flow director struct rte_flow_item_raw guild

[dpdk-users] Flow director struct rte_flow_item_raw guild

[曾懷恩]

Hi, 

I have a few questions about structure rte_flow_item_raw.

In DPDK API doc, it shows there are some below elements in this structure

uint32_t	relative:1
uint32_t	search:1
uint32_t	reserved:30
int32_t 	offset
uint16_t	limit
uint16_t	length
const uint8_t * 	pattern

 Now I can understand the relative and search elements are used to determine search type.

The offset element is used to set the start search point in packet.

The limit element is used to set the end search point in packet.

However, I can’t understand what the pattern element is used to?

What kind of pointer should I assign to the pattern element?

Besides, in other rte_flow_item_* structures, there are clearly elements to let user to set contents and masks.

How do I do in the structure rte_flow_item_raw?

Thanks a lot,

Best Regards,

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[張敬昊]

Hi 懷恩,

On the second line of the detailed description of the struct reference
<https://doc.dpdk.org/api/structrte__flow__item__raw.html#a0ea66fcaa4ad84410cef13b693809bd2>,
it says
"Matches a byte string of a given length at a given offset."

I think *pattern* is the byte string to look for.

Regards,
Frank

On Thu, May 9, 2019 at 10:01 AM 曾懷恩 <the@csie.io> wrote:

>
> Hi,
>
> I have a few questions about structure rte_flow_item_raw.
>
> In DPDK API doc, it shows there are some below elements in this structure
>
> uint32_t        relative:1
> uint32_t        search:1
> uint32_t        reserved:30
> int32_t         offset
> uint16_t        limit
> uint16_t        length
> const uint8_t *         pattern
>
>  Now I can understand the relative and search elements are used to
> determine search type.
>
> The offset element is used to set the start search point in packet.
>
> The limit element is used to set the end search point in packet.
>
> However, I can’t understand what the pattern element is used to?
>
> What kind of pointer should I assign to the pattern element?
>
> Besides, in other rte_flow_item_* structures, there are clearly elements
> to let user to set contents and masks.
>
> How do I do in the structure rte_flow_item_raw?
>
> Thanks a lot,
>
> Best Regards,
>
>

-- 
張敬昊 Frank Chang
Email: frank@csie.io
https://frankchang.me

*High Speed Network Lab <http://speed.cis.nctu.edu.tw/>*
*National Chiao Tung University*

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[曾懷恩]

Hi, 敬昊,

Sorry for my question is not clear.

My question is, should I declare a variable to store the bytes I want to filter and just assign it to the pattern element?

Therefore, will the result of init flow filter be like 

	struct rte_flow_item_raw raw_spec, raw_mask; 
	uint8_t spec[12] = {0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01}; 
	 uint8_t mask[12] = {0xff,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff};

	*(uint32_t *)&raw_spec = 0x40000000;
	raw_spec.offset = 12;
	raw_spec.limit = 12;
	raw_spec.length = 24;
	raw_spec.pattern = spec;
	raw_mask.pattern = mask;
	pattern[0].type = RTE_FLOW_ITEM_TYPE_RAW;
	pattern[0].spec = &raw_spec;
	pattern[0].mask = &raw_mask;

if i want to filter out icmp packet?

thanks a lot.

Best Regards,


> 張敬昊 <frank@csie.io> 於 2019年5月9日 上午10:10 寫道：
> 
> Hi 懷恩,
> 
> On the second line of the detailed description of the struct reference <https://doc.dpdk.org/api/structrte__flow__item__raw.html#a0ea66fcaa4ad84410cef13b693809bd2>, it says
> "Matches a byte string of a given length at a given offset."
> 
> I think pattern is the byte string to look for.
> 
> Regards,
> Frank
> 
> On Thu, May 9, 2019 at 10:01 AM 曾懷恩 <the@csie.io <mailto:the@csie.io>> wrote:
> 
> Hi, 
> 
> I have a few questions about structure rte_flow_item_raw.
> 
> In DPDK API doc, it shows there are some below elements in this structure
> 
> uint32_t        relative:1
> uint32_t        search:1
> uint32_t        reserved:30
> int32_t         offset
> uint16_t        limit
> uint16_t        length
> const uint8_t *         pattern
> 
>  Now I can understand the relative and search elements are used to determine search type.
> 
> The offset element is used to set the start search point in packet.
> 
> The limit element is used to set the end search point in packet.
> 
> However, I can’t understand what the pattern element is used to?
> 
> What kind of pointer should I assign to the pattern element?
> 
> Besides, in other rte_flow_item_* structures, there are clearly elements to let user to set contents and masks.
> 
> How do I do in the structure rte_flow_item_raw?
> 
> Thanks a lot,
> 
> Best Regards,
> 
> 
> 
> -- 
> 張敬昊 Frank Chang
> Email: frank@csie.io <mailto:frank@csie.io>
> https://frankchang.me <https://frankchang.me/>
> 
> High Speed Network Lab <http://speed.cis.nctu.edu.tw/>
> National Chiao Tung University

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[Adrien Mazarguil]

Hi,

On Thu, May 09, 2019 at 11:51:14AM +0800, 曾懷恩 wrote:
> Hi, 敬昊,
> 
> Sorry for my question is not clear.
> 
> My question is, should I declare a variable to store the bytes I want to filter and just assign it to the pattern element?

Yes, this is how it should work.

> 
> Therefore, will the result of init flow filter be like 
> 
> 	struct rte_flow_item_raw raw_spec, raw_mask; 

Just make sure to properly initialize these objects, especially unused
fields. I'll assume something like that was done at some point:

 memset(&raw_spec, 0, sizeof(raw_spec));
 memset(&raw_mask, 0, sizeof(raw_mask));

> 	uint8_t spec[12] = {0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01}; 
> 	 uint8_t mask[12] = {0xff,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff};

This mask will match the first 1st, 2nd and 12th bytes exactly, with
anything in between, i.e. IPv4's EtherType and ICMP protocol type in
subsequent IPv4 header. Seems correct.

> 	*(uint32_t *)&raw_spec = 0x40000000;
> 	raw_spec.offset = 12;
> 	raw_spec.limit = 12;

Note .limit is only meaningful when .search is enabled.

> 	raw_spec.length = 24;

This is the length of the byte pattern itself (12), it must not cover the
offset (12 + 12). In short raw_spec.length must be sizeof(spec).

> 	raw_spec.pattern = spec;
> 	raw_mask.pattern = mask;
> 	pattern[0].type = RTE_FLOW_ITEM_TYPE_RAW;
> 	pattern[0].spec = &raw_spec;
> 	pattern[0].mask = &raw_mask;
> 
> if i want to filter out icmp packet?

Almost... One issue is that, since you chose to provide your own empty mask
(raw_mask) instead of relying on the default one which happens to match all
fields exactly, you must also mask the relevant spec bits, e.g.:

 raw_mask.offset = -1;
 raw_mask.length = -1;

The only exception to this kind of masking is "raw_mask.pattern", which
should contain a valid pointer instead of a bit-mask when raw_spec.length &
raw_mask.length is nonzero.

Documentation example relies on the default mask so this part may not be
quite clear, so let me clarify:

Bit-masking does not apply to pointers the way it does with other types as
it makes no sense to mask them partially. They are either NULL or valid, so
in this specific case, the engine relies on another field (length) to
determine if spec.pattern can be dereferenced.

If length is nonzero, then mask.pattern is checked. If non-NULL, it can be
dereferenced, otherwise the engine defaults to matching "length" bytes from
spec.pattern exactly, hence the use of NULL as the default value in
rte_flow_item_raw_mask.

To summarize, here's how I'd rewrite your example (relying on C99 syntax to
initialize unspecified fields to zero without explicit memset() calls):

 uint8_t raw_pat_data[] = { [0] = 0x08, [1] = 0x00, [11] = 0x01 };
 uint8_t raw_pat_mask[] = { [0] = 0xff, [1] = 0xff, [11] = 0xff };
 struct rte_flow_item_raw raw_spec = {
     .offset = 12,
     .length = sizeof(raw_pat_data),
     .pattern = raw_pat_data,
 };
 struct rte_flow_item_raw raw_mask = {
     .offset = -1,
     .length = -1,
     .pattern = raw_pat_mask,
 };
 struct rte_flow_item pattern[] = {
     {
         .type = RTE_FLOW_ITEM_TYPE_RAW,
         .spec = &raw_spec,
         .mask = &raw_mask,
     },
     {
         .type = RTE_FLOW_ITEM_TYPE_END,
     },
 };

Or alternatively, using two pattern items and relying on the default mask to
avoid punching holes in the byte pattern:

 struct rte_flow_item_raw raw_spec[] = {
     {
         .offset = 12,
         .length = 2,
         .pattern = (uint8_t []){ 0x08, 0x00 },
     },
     {
         .offset = 23, /* or 11 with .relative = 1 */
         .length = 1,
         .pattern = (uint8_t []){ 0x01 },
     },
 };
 struct rte_flow_item pattern[] = {
     {
         .type = RTE_FLOW_ITEM_TYPE_RAW,
         .spec = &raw_spec[0],
     },
     {
         .type = RTE_FLOW_ITEM_TYPE_RAW,
         .spec = &raw_spec[1],
     },
     {
         .type = RTE_FLOW_ITEM_TYPE_END,
     },
 };

Now in practice I never had a chance to use this pattern item with any PMDs
that support it, so I don't know close their behavior sticks to what I just
described, especially regarding the handling of mask.pattern. Do not
hesitate to report odd or inconsistent behavior in any case.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[曾懷恩]

Hi Adrien, thanks for reply and explanation 

I can understand the principle now.

However, I try to merge your rewriting code to mine and the ICMP packets seem not to fit this rule.

My ethernet card is Connectx-4 lx.

Can you give me some suggestion?

Thanks a lot.

Best Regards,

> Adrien Mazarguil <adrien.mazarguil@6wind.com> 於 2019年5月9日 下午8:38 寫道：
> 
> rte_flow_item_raw_mask

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[Adrien Mazarguil]

On Fri, May 10, 2019 at 02:38:56PM +0800, 曾懷恩 wrote:
> Hi Adrien, thanks for reply and explanation 
> 
> I can understand the principle now.
> 
> However, I try to merge your rewriting code to mine and the ICMP packets seem not to fit this rule.
> 
> My ethernet card is Connectx-4 lx.

Bad news then, you can't match ICMP using RAW pattern items with mlx5
yet. According to "git grep -l RTE_FLOW_ITEM_TYPE_RAW drivers/net" so far
only e1000/igb, enic, i40e, ixgbe and softnic PMDs provide some form of
support for RTE_FLOW_ITEM_RAW.

> Can you give me some suggestion?

Since RTE_FLOW_ITEM_TYPE_ICMP is neither supported by mlx5, how about
directly matching the protocol field inside IPv4 headers?

 struct rte_flow_item_ipv4 item_ipv4[] = {
     {
         .hdr.next_proto_id = 0x01,
     },
     {
         .hdr.next_proto_id = 0xff,
     },
 };
 struct rte_flow_pattern pattern[] = {
     {
         .type = RTE_FLOW_ITEM_TYPE_IPV4,
         .spec = &item_ipv4[0],
         .mask = &item_ipv4[1],
     },
     {
         .type = RTE_FLOW_ITEM_TYPE_END,
     },
 };

Should be all it takes to match ICMPv4 packets. Compared to the RAW
approach, this one should also match ICMP traffic inside recognized VLAN,
QinQ and tunnel types (e.g. VXLAN) at no extra cost.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[Huai-En Tseng]

Thanks for reply,

Actually I’d like to use  rte_flow_item_raw structure with PPP header, the ICMP format is my little trial.

I will try X520 next week.

Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW?

Best Regards,

> Adrien Mazarguil <adrien.mazarguil@6wind.com> 於 2019年5月10日 下午9:44 寫道：
> 
> git grep -l RTE_FLOW_ITEM_TYPE_RAW drivers/net

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[Adrien Mazarguil]

On Sat, May 11, 2019 at 02:20:48AM +0800, Huai-En Tseng wrote:
> Thanks for reply,
> 
> Actually I’d like to use  rte_flow_item_raw structure with PPP header, the ICMP format is my little trial.

OK, makes sense, there's no pattern item for PPP yet.

> I will try X520 next week.
> 
> Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW?

The ixgbe driver looks like it does but I'm not sure regarding the VF
variant, Cc'ing maintainers just in case.

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[曾懷恩]

Hi Adrien, 

Thanks for reply,

I tried to trace the mlx5 and ixgbe driver source code in DPDK source and notice that the flow director APIs are processed in it.

I also compared the difference of flow director APIs between both two drivers and found that there is no rte_flow_item_raw defined in mlx5 driver.

Is there any possible mlx5 series NICs support rte_flow_item_raw in the future?

Thanks a lot.

Best Regards,

> Adrien Mazarguil <adrien.mazarguil@6wind.com> 於 2019年5月13日 下午4:49 寫道：
> 
> On Sat, May 11, 2019 at 02:20:48AM +0800, Huai-En Tseng wrote:
>> Thanks for reply,
>> 
>> Actually I’d like to use  rte_flow_item_raw structure with PPP header, the ICMP format is my little trial.
> 
> OK, makes sense, there's no pattern item for PPP yet.
> 
>> I will try X520 next week.
>> 
>> Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW?
> 
> The ixgbe driver looks like it does but I'm not sure regarding the VF
> variant, Cc'ing maintainers just in case.
> 
> -- 
> Adrien Mazarguil
> 6WIND

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[Tom Barbette]

Hi,

I learned to look at the datasheet first, or look at the code before 
using "fancy" patterns (specially for Mellanox products that have no 
datasheet :p).
Another way is to just try testpmd "flow create ..." quickly and see how 
it goes.

Eg, for x520, you will have only access to what is called the 2 flex 
bytes, see the 82599 datasheet.

If you grep the code you'll see the constraint are quite huge :

It will fail if any of these is true :
Mask :
	raw_mask->pattern[0] != 0xff ||
             raw_mask->pattern[1] != 0xff)
--> It's a fixed value search on two bytes. And you'll have to set that 
value for all patterns if I remember the datasheet correctly.

Value:
		raw_spec->relative != 0 ||
             raw_spec->search != 0 ||
             raw_spec->reserved != 0 ||
             raw_spec->offset > IXGBE_MAX_FLX_SOURCE_OFF ||
             raw_spec->offset % 2 ||
             raw_spec->limit != 0 ||
             raw_spec->length != 2 ||
             /* pattern can't be 0xffff */
             (raw_spec->pattern[0] == 0xff &&
              raw_spec->pattern[1] == 0xff))

I think XL710 (i40e) will be as restrained. From what I remember the 
flex bytes became a flex payload bytes. So you can't even match on the 
header.


Tom


For relevance, other mask stuff :
    raw_mask->relative != 0x1 ||
             raw_mask->search != 0x1 ||
             raw_mask->reserved != 0x0 ||
             (uint32_t)raw_mask->offset != 0xffffffff ||
             raw_mask->limit != 0xffff ||
             raw_mask->length != 0xffff




Le 16/05/2019 à 07:34, 曾懷恩 a écrit :
> Hi Adrien,
> 
> Thanks for reply,
> 
> I tried to trace the mlx5 and ixgbe driver source code in DPDK source and notice that the flow director APIs are processed in it.
> 
> I also compared the difference of flow director APIs between both two drivers and found that there is no rte_flow_item_raw defined in mlx5 driver.
> 
> Is there any possible mlx5 series NICs support rte_flow_item_raw in the future?
> 
> Thanks a lot.
> 
> Best Regards,
> 
>> Adrien Mazarguil <adrien.mazarguil@6wind.com> 於 2019年5月13日 下午4:49 寫道：
>>
>> On Sat, May 11, 2019 at 02:20:48AM +0800, Huai-En Tseng wrote:
>>> Thanks for reply,
>>>
>>> Actually I’d like to use  rte_flow_item_raw structure with PPP header, the ICMP format is my little trial.
>>
>> OK, makes sense, there's no pattern item for PPP yet.
>>
>>> I will try X520 next week.
>>>
>>> Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW?
>>
>> The ixgbe driver looks like it does but I'm not sure regarding the VF
>> variant, Cc'ing maintainers just in case.
>>
>> -- 
>> Adrien Mazarguil
>> 6WIND
> 

Re: [dpdk-users] Flow director struct rte_flow_item_raw guild

[曾懷恩]

Hi all,

thanks for previous replying,

I tried to find information about flow director in 82599 ixgbevf.

In the datasheet https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf <https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf>, 

figure 7-7 shows 82599 NIC supports flow director in virtualization case.

However, I got flow creation failed with “function not implemented” when I tried to create a raw flow rule.

Here is the flow I created : 
	struct rte_flow_attr attr;
	struct rte_flow_item pattern[4]; 
	struct rte_flow_action action[4]; 
	struct rte_flow *flow = NULL; 
	struct rte_flow_action_queue queue = { .index = rx_q }; 
	struct rte_flow_item_eth eth_spec, eth_mask;
	struct rte_flow_item_ipv4 ip_spec, ip_mask; 

	memset(pattern,0,sizeof(pattern));
	memset(action,0,sizeof(action));
	memset(&attr,0,sizeof(struct rte_flow_attr));
	attr.ingress = 1;

	action[0].type = RTE_FLOW_ACTION_TYPE_QUEUE;
	action[0].conf = &queue;
	action[1].type = RTE_FLOW_ACTION_TYPE_END;

	memset(&eth_spec,0,sizeof(struct rte_flow_item_eth));
	memset(&eth_mask,0,sizeof(struct rte_flow_item_eth));
	for(int i=0; i<ETH_ALEN; i++) {
		eth_spec.dst.addr_bytes[i] = mac_addr[port_id][i];
		eth_mask.dst.addr_bytes[i] = 0xff;
	}
	eth_spec.type = rte_cpu_to_be_16(0x0800);
	eth_mask.type = 0xffff;
	pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH;
	pattern[0].spec = &eth_spec;
	pattern[0].mask = &eth_mask;

	memset(&ip_spec,0,sizeof(struct rte_flow_item_ipv4));
	memset(&ip_mask,0,sizeof(struct rte_flow_item_ipv4));
	ip_spec.hdr.next_proto_id = 0x06;
	ip_mask.hdr.next_proto_id = 0xff;
	
	pattern[1].type = RTE_FLOW_ITEM_TYPE_IPV4;
	pattern[1].spec = &ip_spec;
	pattern[1].mask = &ip_mask;
	pattern[2].type = RTE_FLOW_ITEM_TYPE_END;

I also tried the DPDK flow_filtering sample application and got failed.

It shows the same error message when creating flow.

It looks like ixgbevf doesn’t support flow director but this seems to conflict with the 82599 datasheet.

Is there anything I miss?

Thanks, 

Best Regards,

> Tom Barbette <barbette@kth.se> 於 2019年5月16日 下午2:00 寫道：
> 
> Hi,
> 
> I learned to look at the datasheet first, or look at the code before using "fancy" patterns (specially for Mellanox products that have no datasheet :p).
> Another way is to just try testpmd "flow create ..." quickly and see how it goes.
> 
> Eg, for x520, you will have only access to what is called the 2 flex bytes, see the 82599 datasheet.
> 
> If you grep the code you'll see the constraint are quite huge :
> 
> It will fail if any of these is true :
> Mask :
> 	raw_mask->pattern[0] != 0xff ||
>            raw_mask->pattern[1] != 0xff)
> --> It's a fixed value search on two bytes. And you'll have to set that value for all patterns if I remember the datasheet correctly.
> 
> Value:
> 		raw_spec->relative != 0 ||
>            raw_spec->search != 0 ||
>            raw_spec->reserved != 0 ||
>            raw_spec->offset > IXGBE_MAX_FLX_SOURCE_OFF ||
>            raw_spec->offset % 2 ||
>            raw_spec->limit != 0 ||
>            raw_spec->length != 2 ||
>            /* pattern can't be 0xffff */
>            (raw_spec->pattern[0] == 0xff &&
>             raw_spec->pattern[1] == 0xff))
> 
> I think XL710 (i40e) will be as restrained. From what I remember the flex bytes became a flex payload bytes. So you can't even match on the header.
> 
> 
> Tom
> 
> 
> For relevance, other mask stuff :
>   raw_mask->relative != 0x1 ||
>            raw_mask->search != 0x1 ||
>            raw_mask->reserved != 0x0 ||
>            (uint32_t)raw_mask->offset != 0xffffffff ||
>            raw_mask->limit != 0xffff ||
>            raw_mask->length != 0xffff
> 
> 
> 
> 
> Le 16/05/2019 à 07:34, 曾懷恩 a écrit :
>> Hi Adrien,
>> Thanks for reply,
>> I tried to trace the mlx5 and ixgbe driver source code in DPDK source and notice that the flow director APIs are processed in it.
>> I also compared the difference of flow director APIs between both two drivers and found that there is no rte_flow_item_raw defined in mlx5 driver.
>> Is there any possible mlx5 series NICs support rte_flow_item_raw in the future?
>> Thanks a lot.
>> Best Regards,
>>> Adrien Mazarguil <adrien.mazarguil@6wind.com> 於 2019年5月13日 下午4:49 寫道：
>>> 
>>> On Sat, May 11, 2019 at 02:20:48AM +0800, Huai-En Tseng wrote:
>>>> Thanks for reply,
>>>> 
>>>> Actually I’d like to use  rte_flow_item_raw structure with PPP header, the ICMP format is my little trial.
>>> 
>>> OK, makes sense, there's no pattern item for PPP yet.
>>> 
>>>> I will try X520 next week.
>>>> 
>>>> Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW?
>>> 
>>> The ixgbe driver looks like it does but I'm not sure regarding the VF
>>> variant, Cc'ing maintainers just in case.
>>> 
>>> -- 
>>> Adrien Mazarguil
>>> 6WIND
>