Re: [dpdk-dev] [PATCH v2 1/2] ethdev: introduce conntrack flow action and item

[Ajit Khaparde <ajit.khaparde@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

On Fri, Apr 16, 2021 at 11:10 PM Bing Zhao <bingz@nvidia.com> wrote:
>
> Hi Ajit,
>
> > -----Original Message-----
> > From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > Sent: Saturday, April 17, 2021 5:47 AM
> > To: Bing Zhao <bingz@nvidia.com>
> > Cc: Ori Kam <orika@nvidia.com>; NBU-Contact-Thomas Monjalon
> > <thomas@monjalon.net>; ferruh.yigit@intel.com;
> > andrew.rybchenko@oktetlabs.ru; dev@dpdk.org
> > Subject: Re: [PATCH v2 1/2] ethdev: introduce conntrack flow action
> > and item
> >
> > > > > +
> > > > > +/**
> > > > > + * @warning
> > > > > + * @b EXPERIMENTAL: this structure may change without prior
> > > > notice
> > > > > + *
> > > > > + * Configuration parameters for each direction of a TCP
> > > > connection.
> > > > > + */
> > > > > +struct rte_flow_tcp_dir_param {
> > > > > +   uint32_t scale:4; /**< TCP window scaling factor, 0xF to
> > > > disable. */
> > > > > +   uint32_t close_initiated:1; /**< The FIN was sent by this
> > > > direction. */
> > > > > +   /**< An ACK packet has been received by this side. */
> > > > > +   uint32_t last_ack_seen:1;
> > > > > +   /**< If set, indicates that there is unacked data of the
> > > > connection. */
> > > > > +   uint32_t data_unacked:1;
> > > > > +   /**< Maximal value of sequence + payload length over sent
> > > > > +    * packets (next ACK from the opposite direction).
> > > > > +    */
> > > > > +   uint32_t sent_end;
> > > > > +   /**< Maximal value of (ACK + window size) over received
> > packet
> > > > +
> > > > > length
> > > > > +    * over sent packet (maximal sequence could be sent).
> > > > > +    */
> > > > > +   uint32_t reply_end;
> > > >
> > > > This comment is for all members that are part of the packet, Do
> > you
> > > > think it should be in network order?
> > >
> > > Almost none of the fields are part of the packet. Indeed, most of
> > them are calculated from the packets information. So I prefer to
> > keep the host order easy for using and
> > > keep all the fields of the whole structure the same endianness
> > format.
> > > What do you think?
> >
> > Can you mention it in the documentation and comments?
> > That all the values are in host byte order and need to be converted
> > to
> > network byte order if the HW needs it that way
>
> Sure, I think it would be better to add it in the documentation.
> What do you think?
Documentation - yes.
In the comments of the structure in the header file - if possible.

>
> BR. Bing