[dpdk-dev] [RFC 0/8] mbuf: structure reorganization
Olivier Matz
olivier.matz at 6wind.com
Tue Feb 28 11:50:43 CET 2017
On Tue, 28 Feb 2017 10:29:41 +0000, "Ananyev, Konstantin"
<konstantin.ananyev at intel.com> wrote:
> >
> > Hi,
> >
> > On Tue, 28 Feb 2017 09:05:07 +0000, "Ananyev, Konstantin"
> > <konstantin.ananyev at intel.com> wrote:
> > > Hi everyone,
> > >
> > > > >
> > > > > In my opinion, if we have the room in the first cache line, we
> > > > > should put it there. The only argument I see against is "we
> > > > > may find something more important in the future, and we won't
> > > > > have room for it in the first cache line". I don't feel we
> > > > > should penalize today's use cases for hypothetic future use
> > > > > cases.
> > > > >
> > > > >
> > > > >
> > > > >> 2. timestamp normalization point
> > > > >> inside PMD RX vs somewhere later as user needs it (extra
> > > > >> function in dev_ops?).
> > > > >
> > > > > This point could be changed. My initial proposition tries to
> > > > > provide a generic API for timestamp. Let me remind it here:
> > > > >
> > > > > a- the timestamp is in nanosecond
> > > > > b- the reference is always the same for a given path: if the
> > > > > timestamp is set in a PMD, all the packets for this PMD will
> > > > > have the same reference, but for 2 different PMDs (or a sw
> > > > > lib), the reference would not be the same.
> > > > >
> > > > > We may remove a-, and just have:
> > > > > - the reference and the unit are always the same for a given
> > > > > path: if the timestamp is set in a PMD, all the packets for
> > > > > this PMD will have the same reference and unit, but for 2
> > > > > different PMDs (or a sw lib), they would not be the same.
> > > > >
> > > > > In both cases, we would need a conversion code (maybe in a
> > > > > library) if the application wants to work with timestamps from
> > > > > several sources. The second solution removes the normalization
> > > > > code in the PMD when not needed, it is probably better.
> > > >
> > > > I agree.
> > >
> > > One question - does that mean that application would need to
> > > keep a track from what PMD each particular packet came to do the
> > > normalization? Konstantin
> >
> > I'd say yes. It does not look very difficult to do, since the mbuf
> > contains the input port id.
> >
>
> I understand that we can use mbuf->port here, but it means that we'll
> introduce new implicit dependency between timestamp and port values.
> From my point that introduces new implications:
> 1. all PMDs that do set a timestamp would also have to set port value too.
> Probably not a big deal as most of PMDs do set port value anyway right now,
> but it means it would be hard to get rid/change mbuf->port in future.
Currently, all PMDs must set m->port.
If in the future we remove m->port, the applications that use it will need
to store the value in a mbuf metadata, or pass it as arguments through function
calls.
> 2. Applications would not allowed to change mbuf->port value before normalization is done
> (from what I heard some apps do update mbuf->port to store routing decisions).
> BTW, how the app would keep track which mbufs were already normalized, and which were not?
I don't think it should be allowed to change m->port value. Applications that
are doing this are responsible of what they change.
> 3. In theory with eth_dev_detach() - mbuf->port value might be not valid at the point when application
> would decide to do normalization.
>
> So to me all that approach with delayed normalization seems unnecessary overcomplicated.
> Original one suggested by Olivier, when normalization is done in PMD at RX look
> much cleaner and more manageable.
Detaching a device requires a synchronization between control and data plane,
and not only for this use case. In the first solution, the normalization is
partial: unit is nanosecond, but the time reference is different.
So, after the discussion, I'm more convinced by the second solution.
Regards,
Olivier
More information about the dev
mailing list