[dpdk-dev] [PATCH v8 1/3] ethdev: add actions to modify TCP header fields

[Dekel Peled]

Accepted, will send separate patch and v9 later today.

> -----Original Message-----
> From: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> Sent: Monday, July 1, 2019 11:55 AM
> To: Dekel Peled <dekelp at mellanox.com>
> Cc: wenzhuo.lu at intel.com; jingjing.wu at intel.com;
> bernard.iremonger at intel.com; Yongseok Koh <yskoh at mellanox.com>;
> Shahaf Shuler <shahafs at mellanox.com>; Slava Ovsiienko
> <viacheslavo at mellanox.com>; arybchenko at solarflare.com; dev at dpdk.org;
> Ori Kam <orika at mellanox.com>
> Subject: Re: [PATCH v8 1/3] ethdev: add actions to modify TCP header fields
> 
> On Sun, Jun 30, 2019 at 10:59:08AM +0300, Dekel Peled wrote:
> > Add actions:
> > - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> > - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP
> header.
> > - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> > 		header.
> > - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> > 		header.
> >
> > Original work by Xiaoyu Min.
> >
> > This patch introduces a new approach, using a simple integer instead
> > of using an action-specific structure for each of these actions.
> > This approach can be later applied to modify existing actions which
> > require only a single integer.
> >
> > Signed-off-by: Dekel Peled <dekelp at mellanox.com>
> > Acked-by: Andrew Rybchenko <arybchenko at solarflare.com>
> 
> You didn't take Andrew's comment [1] into account, this patch must be split.
> I'll highlight what needs to be moved to a pre-patch below.
> 
> [1]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.
> dpdk.org%2Farchives%2Fdev%2F2019-
> June%2F136101.html&data=02%7C01%7Cdekelp%40mellanox.com%7C0
> 353d4fafe004b4434a608d6fe01d04c%7Ca652971c7d2e4d9ba6a4d149256f461b
> %7C0%7C0%7C636975681078705620&sdata=wrMFZOMT65S6X6d4vTnsF
> AAyRF%2F2dTnonX4Ozy7S930%3D&reserved=0
> 
> [...]
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index a34d012..783a904 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1214,7 +1214,8 @@ Actions
> >  ~~~~~~~
> >
> >  Each possible action is represented by a type. Some have associated
> > -configuration structures. Several actions combined in a list can be
> > assigned
> > +configuration structures, some others use a simple integer.
> > +Several actions combined in a list can be assigned
> >  to a flow rule and are performed in order.
> 
> ^^^^ This must be moved to a separate patch ^^^^
> 
> BTW, how about "configuration structure" -> "configuration object"
> encompassing all kinds of objects once and for all instead? Such a generic
> term will be handy when actions start using floats or function pointers.
> 
> [...]
> >  /**
> > @@ -2140,7 +2172,7 @@ struct rte_flow_action_set_mac {
> >   */
> >  struct rte_flow_action {
> >  	enum rte_flow_action_type type; /**< Action type. */
> > -	const void *conf; /**< Pointer to action configuration structure. */
> > +	const void *conf; /**< Pointer to action configuration. */
> >  };
> 
> ^^^^ This must be moved to a separate patch ^^^^
> 
> Same comment regarding "configuration object".
> 
> --
> Adrien Mazarguil
> 6WIND