RE: mbuf fast-free requirements analysis

["Morten Brørup" <mb@smartsharesystems.com>]

> > > > I wonder if the vector implementations have strong requirements
> that
> > > packets are not segmented...
> > > >
> > > > The i40 driver only sets "tx_simple_allowed" and "tx_vec_allowed"
> > > flags when MBUF_FAST_FREE is set:
> > > >
> > >
> https://elixir.bootlin.com/dpdk/v25.11/source/drivers/net/intel/i40e/i4
> > > 0e_rxtx.c#L3502
> > > >
> > >
> > > Actually, it allows but does not require FAST_FREE. The check is
> just
> > > verifying that the flags with everything *but* FAST_FREE masked out
> is
> > > the
> > > same as the original flags, i.e. FAST_FREE is just ignored.
> >
> > That's not how I read the code:
> > ad->tx_simple_allowed =
> > 	(txq->offloads ==
> > 	 (txq->offloads & RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE) &&
> > 	 txq->tx_rs_thresh >= I40E_TX_MAX_BURST);
> >
> > Look at it with offloads=(MULTI_SEGS|FAST_FREE):
> > simple_allowed = (MULTI_SEGS|FAST_FREE) == (MULTI_SEGS|FAST_FREE) &
> FAST_FREE
> > i.e.:
> > simple_allowed = (MULTI_SEGS|FAST_FREE) == FAST_FREE
> > i.e.: false
> >
> 
> Which is correct. The only flag allowed is FAST_FREE, but its not
> required.
> If the input flags were just MULTI_SEGS, it would end  up as:
> 
> simple_allowed = (MULTI_SEGS) == 0
> i.e. also false
> 
> So the FAST_FREE flag does not affect the result.

OK, now I get it.
It's an obfuscated way of writing:
simple_allowed = (offloads & ~RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE) == 0

Suggest updating for readability next time that code is touched.

The comment "only fast free is allowed" [1] didn't help me either;
I interpreted it as "it's only allowed when fast free is set".
Now that I understand the code, I can also interpret the comment as intended.

[1]: https://elixir.bootlin.com/dpdk/v25.11/source/drivers/net/intel/i40e/i40e_rxtx.c#L3502

Thanks for clarifying, Bruce!