> > > +
> > > +/**
> > > + * @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