[dpdk-users] Why flow can not be created?

[dpdk-users] Why flow can not be created?

[Hideyuki Yamashita]

Hello,

I am trying to use rte_flow with i40e PMD.

What I want to achieve is like following.

 ---(dst MAC=XorY && VID=AorB) ---> PHY --default(VID=B)--> Queue0
                                                                 VID=A && dstMAC=X----> Queue1
                                                                 VID=A && dstMAC=Y----> Queue2

I tried to create flow using testpmd, but failed.

testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / vlan tci is 150 / end quactions inqueue index 1 / end
Caught error type 13 (specific pattern item): cause: 0x17ff5e200, Invalid MAC_addr mask.3, : Invalid argument
testpmd>

Note that I could create flow which matches with dst Mac address.
I could also create flow which matches with VID.

---(dst MAC=XorYorZ) ---> PHY  --default(Z)--> Queue0
                                                      dstMAC=X----> Queue1
                                                       dstMAC=Y----> Queue2

---(VID=AorB) ---> PHY  --default(B)--> Queue0
                                           VID=A-------> Queue1

However when comined those two into one flow, testpmd failed to validate the flow.


Q1. Why above flow can not be created?
Q2. All the NICs supported by i40e-PMD do NOT provide above operation and packet classification features?
Q3. Are there any PMD/NIC which allow above operation?


Thaks in advance,

Hideyuki Yamashita
NTT TechnoCross

Re: [dpdk-users] Why flow can not be created?

[Ye Xiaolong]

Hi,

On 07/19, Hideyuki Yamashita wrote:
>Hello,
>
>I am trying to use rte_flow with i40e PMD.
>
>What I want to achieve is like following.
>
> ---(dst MAC=XorY && VID=AorB) ---> PHY --default(VID=B)--> Queue0
>                                                                 VID=A && dstMAC=X----> Queue1
>                                                                 VID=A && dstMAC=Y----> Queue2
>
>I tried to create flow using testpmd, but failed.
>
>testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / vlan tci is 150 / end quactions inqueue index 1 / end
>Caught error type 13 (specific pattern item): cause: 0x17ff5e200, Invalid MAC_addr mask.3, : Invalid argument
>testpmd>

It failed due to the flow used in your example would use i40e fdir filter, and
currently it doesn't support dst MAC.

>
>Note that I could create flow which matches with dst Mac address.
>I could also create flow which matches with VID.

If you create flow with dst MAC address only, then it's handled by ethertype
filter which supports dst MAC.

Thanks,
Xiaolong

>
>---(dst MAC=XorYorZ) ---> PHY  --default(Z)--> Queue0
>                                                      dstMAC=X----> Queue1
>                                                       dstMAC=Y----> Queue2
>
>---(VID=AorB) ---> PHY  --default(B)--> Queue0
>                                           VID=A-------> Queue1
>
>However when comined those two into one flow, testpmd failed to validate the flow.
>
>
>Q1. Why above flow can not be created?
>Q2. All the NICs supported by i40e-PMD do NOT provide above operation and packet classification features?
>Q3. Are there any PMD/NIC which allow above operation?
>
>
>Thaks in advance,
>
>Hideyuki Yamashita
>NTT TechnoCross
>
>

Re: [dpdk-users] Why flow can not be created?

[Hideyuki Yamashita]

Hello Ye,

Thanks for your quick reponse.
Please see inline tagged with [Hideyuki]

> Hi,
> 
> On 07/19, Hideyuki Yamashita wrote:
> >Hello,
> >
> >I am trying to use rte_flow with i40e PMD.
> >
> >What I want to achieve is like following.
> >
> > ---(dst MAC=XorY && VID=AorB) ---> PHY --default(VID=B)--> Queue0
> >                                                                 VID=A && dstMAC=X----> Queue1
> >                                                                 VID=A && dstMAC=Y----> Queue2
> >
> >I tried to create flow using testpmd, but failed.
> >
> >testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / vlan tci is 150 / end quactions inqueue index 1 / end
> >Caught error type 13 (specific pattern item): cause: 0x17ff5e200, Invalid MAC_addr mask.3, : Invalid argument
> >testpmd>
> 
> It failed due to the flow used in your example would use i40e fdir filter, and
> currently it doesn't support dst MAC.
[Hideyuki]
Are there any special reason why dst MAC is NOT supported by
i40e_flow_parse_fdir_filter()?

Maybe this is related to the following my original question.
> >Q2. All the NICs supported by i40e-PMD do NOT provide above operation and packet classification features?


> >
> >Note that I could create flow which matches with dst Mac address.
> >I could also create flow which matches with VID.
> 
> If you create flow with dst MAC address only, then it's handled by ethertype
> filter which supports dst MAC.
[Hideyuki]
Yes, I confirmed it.

Are there any way to achieve my goal by combining two flows
(one for dst MAC and other for VID)?


Also it is appreciated if you or someone can provide answer 
for my question below.
> >Q3. Are there any PMD/NIC which allow above operation?

Thanks!

BR,
Hideyuki Yamashita
NTT TechnoCross


> Thanks,
> Xiaolong
> 
> >
> >---(dst MAC=XorYorZ) ---> PHY  --default(Z)--> Queue0
> >                                                      dstMAC=X----> Queue1
> >                                                       dstMAC=Y----> Queue2
> >
> >---(VID=AorB) ---> PHY  --default(B)--> Queue0
> >                                           VID=A-------> Queue1
> >
> >However when comined those two into one flow, testpmd failed to validate the flow.
> >
> >
> >Q1. Why above flow can not be created?
> >Q2. All the NICs supported by i40e-PMD do NOT provide above operation and packet classification features?
> >Q3. Are there any PMD/NIC which allow above operation?
> >
> >
> >Thaks in advance,
> >
> >Hideyuki Yamashita
> >NTT TechnoCross
> >
> >

Re: [dpdk-users] Why flow can not be created?

[Hideyuki Yamashita]

Hello,

Does anybody whether PMD other than i40e support
VID+dstMAC matching?

It is very hard for me to read all PMD code for just to know
the support of VID+dstMAC as matching pattern.

Somebody, please help me.

BR,
HIdeyuki Yamashita
NTT TechnoCross

> Hello Ye,
> 
> Thanks for your quick reponse.
> Please see inline tagged with [Hideyuki]
> 
> > Hi,
> > 
> > On 07/19, Hideyuki Yamashita wrote:
> > >Hello,
> > >
> > >I am trying to use rte_flow with i40e PMD.
> > >
> > >What I want to achieve is like following.
> > >
> > > ---(dst MAC=XorY && VID=AorB) ---> PHY --default(VID=B)--> Queue0
> > >                                                                 VID=A && dstMAC=X----> Queue1
> > >                                                                 VID=A && dstMAC=Y----> Queue2
> > >
> > >I tried to create flow using testpmd, but failed.
> > >
> > >testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / vlan tci is 150 / end quactions inqueue index 1 / end
> > >Caught error type 13 (specific pattern item): cause: 0x17ff5e200, Invalid MAC_addr mask.3, : Invalid argument
> > >testpmd>
> > 
> > It failed due to the flow used in your example would use i40e fdir filter, and
> > currently it doesn't support dst MAC.
> [Hideyuki]
> Are there any special reason why dst MAC is NOT supported by
> i40e_flow_parse_fdir_filter()?
> 
> Maybe this is related to the following my original question.
> > >Q2. All the NICs supported by i40e-PMD do NOT provide above operation and packet classification features?
> 
> 
> > >
> > >Note that I could create flow which matches with dst Mac address.
> > >I could also create flow which matches with VID.
> > 
> > If you create flow with dst MAC address only, then it's handled by ethertype
> > filter which supports dst MAC.
> [Hideyuki]
> Yes, I confirmed it.
> 
> Are there any way to achieve my goal by combining two flows
> (one for dst MAC and other for VID)?
> 
> 
> Also it is appreciated if you or someone can provide answer 
> for my question below.
> > >Q3. Are there any PMD/NIC which allow above operation?
> 
> Thanks!
> 
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> > Thanks,
> > Xiaolong
> > 
> > >
> > >---(dst MAC=XorYorZ) ---> PHY  --default(Z)--> Queue0
> > >                                                      dstMAC=X----> Queue1
> > >                                                       dstMAC=Y----> Queue2
> > >
> > >---(VID=AorB) ---> PHY  --default(B)--> Queue0
> > >                                           VID=A-------> Queue1
> > >
> > >However when comined those two into one flow, testpmd failed to validate the flow.
> > >
> > >
> > >Q1. Why above flow can not be created?
> > >Q2. All the NICs supported by i40e-PMD do NOT provide above operation and packet classification features?
> > >Q3. Are there any PMD/NIC which allow above operation?
> > >
> > >
> > >Thaks in advance,
> > >
> > >Hideyuki Yamashita
> > >NTT TechnoCross
> > >
> > >
> 
> 

Re: [dpdk-users] Why flow can not be created?

[Adrien Mazarguil]

On Tue, Jul 30, 2019 at 07:37:38PM +0900, Hideyuki Yamashita wrote:
> Hello,
> 
> Does anybody whether PMD other than i40e support
> VID+dstMAC matching?
> 
> It is very hard for me to read all PMD code for just to know
> the support of VID+dstMAC as matching pattern.
> 
> Somebody, please help me.

Unfortunately right now trial & error using testpmd is the most effective
approach to determine whether specific combinations are supported by any
given NIC.

Ideally doc/guides/nics/features.rst [1] should document each rte_flow
feature reflected in doc/guide/nics/features/*.ini for individual PMDs [2],
but that list is currently too incomplete to be useful.

Now to answer your question, although those are likely not the only ones, I
know from experience that both mlx4 and mlx5 support flow rules matching VID
+ dst MAC simultaneously.

[1] http://doc.dpdk.org/guides/nics/features.html

[2] http://doc.dpdk.org/guides/nics/overview.html

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-users] Why flow can not be created?

[Hideyuki Yamashita]

Hello Adrien,

Thanks for your answer.
Now I understand the situation.

I will try to test mlx4 or mlx5.

Thanks again.
BR,
Hideyuki Yamashita
NTT TechnoCross

> On Tue, Jul 30, 2019 at 07:37:38PM +0900, Hideyuki Yamashita wrote:
> > Hello,
> > 
> > Does anybody whether PMD other than i40e support
> > VID+dstMAC matching?
> > 
> > It is very hard for me to read all PMD code for just to know
> > the support of VID+dstMAC as matching pattern.
> > 
> > Somebody, please help me.
> 
> Unfortunately right now trial & error using testpmd is the most effective
> approach to determine whether specific combinations are supported by any
> given NIC.
> 
> Ideally doc/guides/nics/features.rst [1] should document each rte_flow
> feature reflected in doc/guide/nics/features/*.ini for individual PMDs [2],
> but that list is currently too incomplete to be useful.
> 
> Now to answer your question, although those are likely not the only ones, I
> know from experience that both mlx4 and mlx5 support flow rules matching VID
> + dst MAC simultaneously.
> 
> [1] http://doc.dpdk.org/guides/nics/features.html
> 
> [2] http://doc.dpdk.org/guides/nics/overview.html
> 
> -- 
> Adrien Mazarguil
> 6WIND

Re: [dpdk-users] Why flow can not be created?

[Hideyuki Yamashita]

Helllo Experts,

Q1. Are there any NICs which supports entag/detag VLAN?
I searched source DPDK source code with keyword "OF_POP_VLAN" or "OF_POP_VLAN"
and found some codes within mlx5_flow_tcf.c and cxgbe_flow.c.

Q2. Are there any plans in DPDK community to update document about 
NIC to update support of rte_flow?
I have heard the situation about document form Adrien, and to be honest
I felt it is very hard to take try and error with testpmd for every NIC.

BR<
Hideyuki Yamashita
NTT TechnoCross

Re: [dpdk-users] Why flow can not be created?

[Adrien Mazarguil]

On Fri, Aug 02, 2019 at 03:06:19PM +0900, Hideyuki Yamashita wrote:
> Helllo Experts,

I think most of them are on vacation :)

> Q1. Are there any NICs which supports entag/detag VLAN?
> I searched source DPDK source code with keyword "OF_POP_VLAN" or "OF_POP_VLAN"
> and found some codes within mlx5_flow_tcf.c and cxgbe_flow.c.

Indeed only those two seem to implement that. However depending on what
you're trying to achieve, there could be a workaround as many drivers
provide support for VLAN entag/detag outside rte_flow.

For Rx, you can dedicate queues to perform VLAN stripping through
rte_eth_dev_set_vlan_strip_on_queue(), and use rte_flow to redirect traffic
of interest to these queues after matching specific VLANs and other
properties for instance.

If you don't care about specific VLANs or queues, you can request VLAN
stripping globally using ETH_VLAN_STRIP_OFFLOAD with
rte_eth_dev_set_vlan_offload(), then rely on mbuf->ol_flags & PKT_RX_VLAN to
retrieve it from mbuf->vlan_tci.

On the Tx side you simply have to request mbuf->ol_flags | PKT_TX_VLAN while
doing Tx. As for Rx, make sure DEV_TX_OFFLOAD_VLAN_INSERT is among the Tx
offloads requested during setup (rte_eth_conf->txmode.offloads).

> Q2. Are there any plans in DPDK community to update document about 
> NIC to update support of rte_flow?
> I have heard the situation about document form Adrien, and to be honest
> I felt it is very hard to take try and error with testpmd for every NIC.

This was discussed in the past, however so far no action was taken.

I think we cannot summarize all supported combinations for each NIC while
covering their specific quirks efficiently. For instance, two NICs may
support a given pattern item, but not necessarily at the same position in
the pattern. Likewise for pattern item fields, they may not support the same
masks.

The most sensible approach is perhaps to provide a list of popular flow
rules tagged with the NICs supporting them.

Anyway since it's not a huge priority at the moment, you should start a
discussion on that topic on the dev@dpdk.org mailing list. Without noise,
nothing will happen :) As usual contributions are always welcome!

-- 
Adrien Mazarguil
6WIND

Re: [dpdk-users] Why flow can not be created?

[Moti Haimovsky]

Mlnx5 Patches supporting rte-flow  Vlan push/pop actions were submitted today. 
Moti

> -----Original Message-----
> From: users <users-bounces@dpdk.org> On Behalf Of Adrien Mazarguil
> Sent: Tuesday, August 6, 2019 12:13 PM
> To: Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>
> Cc: Ye Xiaolong <xiaolong.ye@intel.com>; users@dpdk.org
> Subject: Re: [dpdk-users] Why flow can not be created?
> 
> On Fri, Aug 02, 2019 at 03:06:19PM +0900, Hideyuki Yamashita wrote:
> > Helllo Experts,
> 
> I think most of them are on vacation :)
> 
> > Q1. Are there any NICs which supports entag/detag VLAN?
> > I searched source DPDK source code with keyword "OF_POP_VLAN" or
> "OF_POP_VLAN"
> > and found some codes within mlx5_flow_tcf.c and cxgbe_flow.c.
> 
> Indeed only those two seem to implement that. However depending on
> what you're trying to achieve, there could be a workaround as many drivers
> provide support for VLAN entag/detag outside rte_flow.
> 
> For Rx, you can dedicate queues to perform VLAN stripping through
> rte_eth_dev_set_vlan_strip_on_queue(), and use rte_flow to redirect
> traffic of interest to these queues after matching specific VLANs and other
> properties for instance.
> 
> If you don't care about specific VLANs or queues, you can request VLAN
> stripping globally using ETH_VLAN_STRIP_OFFLOAD with
> rte_eth_dev_set_vlan_offload(), then rely on mbuf->ol_flags &
> PKT_RX_VLAN to retrieve it from mbuf->vlan_tci.
> 
> On the Tx side you simply have to request mbuf->ol_flags | PKT_TX_VLAN
> while doing Tx. As for Rx, make sure DEV_TX_OFFLOAD_VLAN_INSERT is
> among the Tx offloads requested during setup (rte_eth_conf-
> >txmode.offloads).
> 
> > Q2. Are there any plans in DPDK community to update document about NIC
> > to update support of rte_flow?
> > I have heard the situation about document form Adrien, and to be
> > honest I felt it is very hard to take try and error with testpmd for every NIC.
> 
> This was discussed in the past, however so far no action was taken.
> 
> I think we cannot summarize all supported combinations for each NIC while
> covering their specific quirks efficiently. For instance, two NICs may support a
> given pattern item, but not necessarily at the same position in the pattern.
> Likewise for pattern item fields, they may not support the same masks.
> 
> The most sensible approach is perhaps to provide a list of popular flow rules
> tagged with the NICs supporting them.
> 
> Anyway since it's not a huge priority at the moment, you should start a
> discussion on that topic on the dev@dpdk.org mailing list. Without noise,
> nothing will happen :) As usual contributions are always welcome!
> 
> --
> Adrien Mazarguil
> 6WIND

Re: [dpdk-users] Why flow can not be created?

[Hideyuki Yamashita]

Hello Adrien,

Thanks for your response.
> On Fri, Aug 02, 2019 at 03:06:19PM +0900, Hideyuki Yamashita wrote:
> > Helllo Experts,
> 
> I think most of them are on vacation :)
[Hideyuki]
I agree.
How about you?

> > Q1. Are there any NICs which supports entag/detag VLAN?
> > I searched source DPDK source code with keyword "OF_POP_VLAN" or "OF_POP_VLAN"
> > and found some codes within mlx5_flow_tcf.c and cxgbe_flow.c.
> 
> Indeed only those two seem to implement that. However depending on what
> you're trying to achieve, there could be a workaround as many drivers
> provide support for VLAN entag/detag outside rte_flow.
> 
> For Rx, you can dedicate queues to perform VLAN stripping through
> rte_eth_dev_set_vlan_strip_on_queue(), and use rte_flow to redirect traffic
> of interest to these queues after matching specific VLANs and other
> properties for instance.
> 
> If you don't care about specific VLANs or queues, you can request VLAN
> stripping globally using ETH_VLAN_STRIP_OFFLOAD with
> rte_eth_dev_set_vlan_offload(), then rely on mbuf->ol_flags & PKT_RX_VLAN to
> retrieve it from mbuf->vlan_tci.
> 
> On the Tx side you simply have to request mbuf->ol_flags | PKT_TX_VLAN while
> doing Tx. As for Rx, make sure DEV_TX_OFFLOAD_VLAN_INSERT is among the Tx
> offloads requested during setup (rte_eth_conf->txmode.offloads).

[Hideyuki]

There are at least 3 alternatives for Entag/Detag VLAN tag in hardware.
Alt1: rte_flow only (mlx5, cxgbe supports?)
Alt2: rte_eth_dev_set_vlan_strip_on_queue() call combine with rte_flow
(route specific traffic to specific quueue) this is applicable for RX only
Alt3: rte_eth_dev_set_vlan_offload()

Q1. Why there are multiple way to achieve same purpose?
(Is it long story?)


> > Q2. Are there any plans in DPDK community to update document about 
> > NIC to update support of rte_flow?
> > I have heard the situation about document form Adrien, and to be honest
> > I felt it is very hard to take try and error with testpmd for every NIC.
> 
> This was discussed in the past, however so far no action was taken.
> 
> I think we cannot summarize all supported combinations for each NIC while
> covering their specific quirks efficiently. For instance, two NICs may
> support a given pattern item, but not necessarily at the same position in
> the pattern. Likewise for pattern item fields, they may not support the same
> masks.
[Hideyuki]
Thanks for summerizing up the problem.
So many combinations to be sorted even for one NIC.
And it makes more difficult to sort out support status for all NICs,
right?
 
> The most sensible approach is perhaps to provide a list of popular flow
> rules tagged with the NICs supporting them.

Maybe it is a very good starting point.
I agree that if it is difficult to sort out "everything", to limit
number is the possible solution
- limit the number of NICs 
or 
- limit the flow rules (typical flows)

> Anyway since it's not a huge priority at the moment, you should start a
> discussion on that topic on the dev@dpdk.org mailing list. Without noise,
> nothing will happen :) As usual contributions are always welcome!

OK.
Thanks I will come back to dev-ml with "what we want from user
perspective".

Thanks for your guidance.

BR,
Hideyuki Yamashita
NTT TechnoCross

> -- 
> Adrien Mazarguil
> 6WIND

------------------------------------------------
NTTテクノクロス株式会社
フューチャーネットワーク事業部　第一事業ユニット
山下　英之(email: yamashita.hideyuki@po.ntt-tx.co.jp)
〒167-0043 東京都杉並区上荻1-2-1 荻窪インテグラルタワー13F
TEL 03-5347-8026    FAX  03-3392-6803
------------------------------------------------------

[dpdk-users] How L2 broadcast is handled under rte_flow?

[Hideyuki Yamashita]

Hello Experts,

I have basic questions on how L2 broadcast is handled under rte_flow.

[Question1]

To which queue L2 broadcast packet will be received?

testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / end actions queue index 1 / end
testpmd> flow create 0 ingress pattern eth dst is 22:33:44:55:66:77 type mask 0xffff / end actions queue index 2 / end

My expectation is both queue 1 and queue 2 receive broadcast(dst MAC is
FF:FF:FF:FF:FF:FF).
Or only default queue (queue 0 ) receive the packet?

If we assume NIC act as switching hub and queues are ports,
broadcast packets will be flooded to all available ports.
Let us assume the situation that there exists software switch
which act like switching hub (deliver packets based on dst MAC),
and I want the function offload to NIC via rte_flow.

[Question2]
What happens if VLAN is involved?

My expectation is as following:
If receive broadcast packet (dst is FF:FF:FF:FF:FF:FF) for specific vlan,
all queues related to this vlan id will receive the broadcast packet.
Is my understanding correct?

It may depends on each rte_flow implementations.
But if there is a rule in common among various NICs, I want to know.

Re: [dpdk-users] How L2 broadcast is handled under rte_flow?

[Hideyuki Yamashita]

Hello Experts,

Can somebody help me?
(Or many people still enjoy summer vacation?)

I think it is very interesting question
how NIC handles L2 broadcast when multiple queues are setup.

Or are there any way(DPDK API) to set NIC to assign all rx queues
when receiving L2 broadcast?

Thanks in advance.
BR,
Hideyuki Yamashita
NTT TechnoCross


> Hello Experts,
> 
> I have basic questions on how L2 broadcast is handled under rte_flow.
> 
> [Question1]
> 
> To which queue L2 broadcast packet will be received?
> 
> testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66 type mask 0xffff / end actions queue index 1 / end
> testpmd> flow create 0 ingress pattern eth dst is 22:33:44:55:66:77 type mask 0xffff / end actions queue index 2 / end
> 
> My expectation is both queue 1 and queue 2 receive broadcast(dst MAC is
> FF:FF:FF:FF:FF:FF).
> Or only default queue (queue 0 ) receive the packet?
> 
> If we assume NIC act as switching hub and queues are ports,
> broadcast packets will be flooded to all available ports.
> Let us assume the situation that there exists software switch
> which act like switching hub (deliver packets based on dst MAC),
> and I want the function offload to NIC via rte_flow.
> 
> [Question2]
> What happens if VLAN is involved?
> 
> My expectation is as following:
> If receive broadcast packet (dst is FF:FF:FF:FF:FF:FF) for specific vlan,
> all queues related to this vlan id will receive the broadcast packet.
> Is my understanding correct?
> 
> It may depends on each rte_flow implementations.
> But if there is a rule in common among various NICs, I want to know.