Hi, On Thu, Oct 24, 2019 at 04:54:20AM +0000, Shahaf Shuler wrote: > Wednesday, October 23, 2019 4:34 PM, Olivier Matz: > > Subject: Re: [dpdk-dev] [PATCH v2] mbuf: support dynamic fields and flags > > > > Hi Shahaf, > > > > On Wed, Oct 23, 2019 at 12:00:30PM +0000, Shahaf Shuler wrote: > > > Hi Olivier, > > > > > > Thursday, October 17, 2019 5:42 PM, Olivier Matz: > > > > Subject: [dpdk-dev] [PATCH v2] mbuf: support dynamic fields and > > > > flags > > > > > > > > Many features require to store data inside the mbuf. As the room in > > > > mbuf structure is limited, it is not possible to have a field for > > > > each feature. Also, changing fields in the mbuf structure can break the > > API or ABI. > > > > > > > > This commit addresses these issues, by enabling the dynamic > > > > registration of fields or flags: > > > > > > > > - a dynamic field is a named area in the rte_mbuf structure, with a > > > > given size (>= 1 byte) and alignment constraint. > > > > - a dynamic flag is a named bit in the rte_mbuf structure. > > > > > > > > The typical use case is a PMD that registers space for an offload > > > > feature, when the application requests to enable this feature. As > > > > the space in mbuf is limited, the space should only be reserved if > > > > it is going to be used (i.e when the application explicitly asks for > > > > it). > > > > > > According to description, the dynamic field enables custom application and > > supported PMDs to use the dynamic part of the mbuf for their specific > > needs. > > > However the mechanism to report and activate the field/flag registration > > comes from the general OFFLOAD flags. > > > > > > Maybe it will be better to an option to query and select dynamic fields > > > for > > PMD outside of the standard ethdev offload flags? > > > > It is not mandatory to use the ethdev layer to register a dynamic field or > > flag > > in the mbuf. It is just the typical use case. > > > > It can also be enabled when using a library that have specific needs, for > > instance, you call rte_reorder_init(), and it will register the sequence > > number > > dynamic field. > > > > An application that requires a specific mbuf field can also do the > > registration > > by itself. > > > > In other words, when you initialize a subpart that needs a dynamic field or > > flag, you have to do the registration there. > > > > I guess my question mainly targets one of the use cases for dynamic mbuf > fields which is vendor specific offloads. > On such case we would like to have dynamic fields/flags negotiated between > the application and PMD. > > The question is whether we provide a unified way for application to query PMD > specific dynamic fields or we let PMD vendor to implement this handshake as > they wish (devargs, through PMD doc, etc..)
I have no strong opinion. It can be a PMD-specific API (function or devargs) to enable the feature. The only important thing is to not register the field if it won't be used.
