15/05/2020 15:44, Nithin Dabilpuram:
> On Fri, May 15, 2020 at 03:12:59PM +0200, Thomas Monjalon wrote:
> > 15/05/2020 12:08, Nithin Dabilpuram:
> > > On Thu, May 14, 2020 at 10:29:31PM +0200, Olivier Matz wrote:
> > > > I don't see any better approach than having a mbuf flag. However, I'm
> > > > still not fully convinced that a dynamic flag won't do the job. Taking
> > > > 3 additional flags (among 18 remaing) for this feature also means that
> > > > we have 3 flags less for dynamic flags for all applications, even for
> > > > applications that will not use this feature.
> > > > 
> > > > Would it be a problem to use a dynamic flag in this case?
> > > Since packet marking feature itself is already part of spec,
> > > if we move the flags to PMD specific dynamic flag, then it creates a 
> > > confusion.
> > > 
> > > It is not the case of a custom feature supported by a specific PMD.
> > > I believe when other PMD's implement packet marking, the same flags will
> > > suffice.
> > 
> > A dynamic flag is not necessarily PMD-specific.
> > It is just avoiding consuming bits if the feature is not used by the 
> > application.
> > We must move more existing flags and fields to be dynamic.
> > 
> > In general, all new flags and fields in mbuf should be dynamic.
> > And a work must be done to move existing stuff to free more space
> > for more dynamic features.
> 
> My bad, I thought dynamic flags can only be used for PMD specific thing.
> 
> There is however a cost of using dynamic flag which I think should be avoided
> for DPDK spec defined offloads, though it's fine for PMD specific things.
> 
> Dynamic offload flags causes application and PMD to use non constant offset 
> or shift which are looked up at init, instead of having a constant shift or
> offset. This indirection costs some cycles due to extra loads in fast path.

Yes there is a cost. We described it quite clearly last year.
The default rule is now to add new flags and fields as dynamic.
In case the rule was not clear, I will send a patch to insert some
notes in the code and the doc.

If you disagree with this new rule, you will have to give very good arguments.




Reply via email to