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

[Hideyuki Yamashita <yamashita.hideyuki@ntt-tx.co.jp>]

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
------------------------------------------------------