>
> > Hardware IP reassembly may be incomplete for multiple reasons like
> > reassembly timeout reached, duplicate fragments, etc.
> > To save application cycles to process these packets again, a new
> > mbuf ol_flag (RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE) is added to
> > show that the mbuf received is not reassembled properly.
>
> If we use dynfiled for data, why not use dynflag for
> RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE?
> That way we can avoid introduced hardcoded (always defined) flags for that
> case.
I have not looked into using dynflag. Will explore if it can be used.
> >
> > +/**
> > + * In case of IP reassembly offload failure, ol_flags in mbuf will be set
> > + * with RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE and packets will be
> returned
> > + * without alteration. The application can retrieve the attached fragments
> > + * using mbuf dynamic field.
> > + */
> > +typedef struct {
> > + /**
> > + * Next fragment packet. Application should fetch dynamic field of
> > + * each fragment until a NULL is received and nb_frags is 0.
> > + */
> > + struct rte_mbuf *next_frag;
> > + /** Time spent(in ms) by HW in waiting for further fragments. */
> > + uint16_t time_spent;
> > + /** Number of more fragments attached in mbuf dynamic fields. */
> > + uint16_t nb_frags;
> > +} rte_eth_ip_reass_dynfield_t;
>
>
> Looks like a bit of overkill to me:
> We do already have 'next' and 'nb_frags' fields inside mbuf,
> why can't they be used here? Why a separate ones are necessary?
>
The next and nb_frags in mbuf is for segmented buffers and not IP fragments.
But here we will have separate mbufs in each dynfield denoting each of the
fragments which may have further segmented buffers.
