[dpdk-dev] [RFC] ethdev: add IPv4/IPv6 DSCP rewrite action

[Suanming Mou]

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Wednesday, December 11, 2019 2:32 AM
> To: Andrew Rybchenko <arybchenko at solarflare.com>
> Cc: Suanming Mou <suanmingm at mellanox.com>; Adrien Mazarguil
> <adrien.mazarguil at 6wind.com>; John McNamara <john.mcnamara at intel.com>;
> Marko Kovacevic <marko.kovacevic at intel.com>; Thomas Monjalon
> <thomas at monjalon.net>; Ferruh Yigit <ferruh.yigit at intel.com>; dev at dpdk.org;
> Shahaf Shuler <shahafs at mellanox.com>; Ori Kam <orika at mellanox.com>;
> Matan Azrad <matan at mellanox.com>; Slava Ovsiienko
> <viacheslavo at mellanox.com>
> Subject: Re: [dpdk-dev] [RFC] ethdev: add IPv4/IPv6 DSCP rewrite action
> 
> On Tue, 10 Dec 2019 10:33:28 +0300
> Andrew Rybchenko <arybchenko at solarflare.com> wrote:
> 
> > > For some overlay network, such as VXLAN, the DSCP field in the new
> > > outer IP header after VXLAN decapsulation may need to be updated
> accordingly.
> > >
> > > This commit introduce the DSCP modify action for IPv4 and IPv6.
> > >
> > > Signed-off-by: Suanming Mou <suanmingm at mellanox.com>
> >
> > Acked-by: Andrew Rybchenko <arybchenko at solarflare.com>
> >
> > as usual it requires testpmd support and a driver which supports it (I
> > understand that it may be omitted in RFC).
> 
> And it requires documentation and a software implementation in the flow
> classifier.

Could you please give the previous example code which add to both of them?

> 
> 
> Plus you conveniently exclude defining what happens to reserved bits.
> "What ever our hardware does is correct" is not a useful answer.
> You need to be precise and limited in what is allowed to make this usable.

Sorry, I feel a little confused.
The DSCP only use 6 bits both in IPv4 and IPv6 header. The data struct is defined by the IP protocol, it is not defined by the hardware.
And the rest bits will be ignored as only 6 bits in the header. It is also added in the code comments.
The action is to apply the 6 bits DSCP value to the 6 bits DSCP field in IPv4 or IPv6 header.
Could you please point out the not precise part much more detail?

Thank you for the comments. Will try to make it better.

> 
> Sorry, to be so negative. This feature is fine in itself and a useful incremental
> improvement. But nobody has stepped up to address the usability of rte_flow.

It's hard to say,  it's just like some people like meat and some like vegetables.