On Fri, Jul 12, 2019 at 05:54:57PM +0300, Andrew Rybchenko wrote: > On 10.07.2019 12:29, Olivier Matz wrote: > > 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). > > > > The registration can be done at any moment, but it is not possible > > to unregister fields or flags for now. > > > > Signed-off-by: Olivier Matz <olivier.m...@6wind.com> > > I like the idea. > > I think it would be very useful to measure performance impact. Since it is > core structure which is heavily used on datapath, performance impact is > required to make decision to go or not to go. If acceptable, more fields > can be converted to dynamic: timestamp, user data, sequence number, > timesync data etc.
Agree. I'll try to do this in the coming days. > Rules on which fields should be static and which > dynamic are required. Timestamp, for example, is located in the first > cache line. Do we need a way prioritize some dynamic fields to be located > (if possible) in the first cache line? Or is it better simply move some > static > to the first cache line instead? There is a "flags" argument, which is designed for this purpose. Today, there is no room in the first cache line, but as soon as we remove something from it, we can add a flag to ask to register a dynamic field in the first cache line. > I think rules should be better defined and imposed, if possible, when > dynamic fields may be registered. Which entities are allowed to register > dynamic fields? I think there is no restriction. Library, PMD, App can register their dynamic fields as soon as there is room for it. > Do we need to keep track which entity has registered > which dynamic fields? Looks quite difficult to me. Most of the time, a dynamic field will be registered at several places. Only the first registration is effective, the other will just get the offset. But at least we could add a log in the registration function. > What to expect if a dynamic field is registered > after port start (the field is registered, but most likely not filled in)? > What to expect on port restart? Registration of dynamic field can be done at any moment. But to register a field that will be used by a PMD, we need to ask for the feature at port configuration (usually through ethdev). Then the PMD will register the dynamic field. If it fails, the configuration of the port should fail. The application that will access to the field will also register it. It can be done before or after the PMD initialization.
