Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Tuesday, October 13, 2020 8:42 PM
> To: Bing Zhao <bi...@nvidia.com>
> Cc: Ori Kam <or...@nvidia.com>; ferruh.yi...@intel.com;
> arybche...@solarflare.com; m...@ashroe.eu; nhor...@tuxdriver.com;
> bernard.iremon...@intel.com; beilei.x...@intel.com;
> wenzhuo...@intel.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 2/6] ethdev: add new attributes to
> hairpin config
>
> External email: Use caution opening links or attachments
>
>
> 13/10/2020 14:29, Bing Zhao:
> > From: Thomas Monjalon <tho...@monjalon.net>
> > > 08/10/2020 14:05, Bing Zhao:
> > > > struct rte_eth_hairpin_conf {
> > > > - uint16_t peer_count; /**< The number of peers. */
> > > > + uint32_t peer_count:16; /**< The number of peers. */
> > >
> > > Why not keeping uint16_t?
> >
> > The inside structure has a multiple of 4B, and the peer_count now
> only takes about 2B. AFAIK, usually, the structure will have an
> aligned length/offset and there will be some padding between the 2B
> + (2B pad) + 4B * 32 or 2B + (2B +2B) * 32 + 2B, depending on the
> compiler.
> > I changed to bit fields of a u32 due to the two facts:
> > 1. Using the 2B and keep the whole structure aligned. No waste
> except the reserved bits.
> > 2. Only u32 with bit fields is standard.
>
> Oh I see, this is because u16 bit fields are not standard?
In some compiler, it is supported. But in the old compiler, it might not and
some warning will be raised.
" nonstandard extension used : bit-field types other than int "
"
The following properties of bit fields are implementation-defined:
Whether bit fields of type int are treated as signed or unsigned
Whether types other than int, signed int, unsigned int, and _Bool (since C99)
are permitted
"
In C11, it should be supported already.
>
> > > > + uint32_t tx_explicit:1; /**< Explicit TX flow rule mode.
> */
> > > > + uint32_t manual_bind:1; /**< Manually bind hairpin
> queues.
> > > */
> > >
> > > Please describe more the expectations of these bits:
> > > What is changed at ethdev or PMD level?
> >
> > In ethdev level, there is almost no change. This attribute will be
> passed to PMD directly through the function pointer.
> > In PMD level, these bits should be checked and better to be saved.
> And the attribute fields should be checked for per queue pair and
> all the queues, and each queue pair should have the same attributes
> configured to make the behavior aligned. But it depends on the PMD
> itself to decide if all the queue pairs between a port pair should
> have the same attributes, or even all the queues from / to same port
> of all hairpin port pairs.
> > If manual_bind is not set, then the PMD will try to bind the
> queues and enable hairpin during device start stage and there is no
> need to call the bind / unbind API.
> > If tx_explicit is set, the application should insert the RX flow
> rules and TX flow rules separately and connect the RX/TX logic
> connection together.
> >
> > > What the application is supposed to do?
> >
> > The application should specify the new two attributes during the
> queue setup. And also, it could leave it unset (0 by default) to
> keep the behavior compatible with the previous release.
> > If manual_bind is set, then it is the application's responsibility
> to call the bind / unbind API to enable / disable the hairpin
> between specific ports.
> > If tx_explicit is set, as described above, the application should
> maintain the flows logic to make hairpin work as expected, e.g.,
> they can choose metadata (not the only method), in the RX flow, the
> metadata is set and in the TX flow, it is used for matching. Then
> even if the headers are changed with NAT action or encap, the
> hairpin function could work as expected.
> >
> > > Why choosing one mode or the other?
> >
> > If the application wants to have the full control of hairpin flows,
> it could chose the explicit TX flow mode.
> > If two or more ports involved into the hairpin, it is suggested to
> use the manual bind.
> > Please note, the actual supported attributes denpend on the PMD
> and HW.
>
> The application impact must be described shortly in doxygen please.
>
>
OK, sure. I added into the commit message. I will also describe it shortly in
the doc.
Thanks
