> -----Original Message-----
> From: Stephen Hemminger <step...@networkplumber.org>
> Sent: Wednesday, December 11, 2019 2:32 AM
> To: Andrew Rybchenko <arybche...@solarflare.com>
> Cc: Suanming Mou <suanmi...@mellanox.com>; Adrien Mazarguil
> <adrien.mazarg...@6wind.com>; John McNamara <john.mcnam...@intel.com>;
> Marko Kovacevic <marko.kovace...@intel.com>; Thomas Monjalon
> <tho...@monjalon.net>; Ferruh Yigit <ferruh.yi...@intel.com>; dev@dpdk.org;
> Shahaf Shuler <shah...@mellanox.com>; Ori Kam <or...@mellanox.com>;
> Matan Azrad <ma...@mellanox.com>; Slava Ovsiienko
> <viachesl...@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 <arybche...@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 <suanmi...@mellanox.com>
> >
> > Acked-by: Andrew Rybchenko <arybche...@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.
