[ovs-dev] [PATCH] dp-packet: Fix clearing/copying of memory layout flags.

[David Marchand]

On Fri, Nov 22, 2019 at 3:04 PM Ilya Maximets <i.maximets at ovn.org> wrote:
> >>> Rather than exclude a set of flags, I would touch/copy only the flags
> >>> that OVS uses/understands.
> >>>
> >>> When OVS uses a DPDK flag, it has an associated API and meaning wrt
> >>> the rte_mbuf and the data.
> >>> - when the flags are reset in OVS, that's because something has been
> >>> done to the data (and the checksums and the rss hash must be
> >>> reevaluated),
> >>> - when a buffer is copied, OVS copies the data and the context that
> >>> matters to OVS,
> >>>
> >>> Anything else should be discarded when copying to a new dp-packet.
> >>
> >> Yes, that was the first version I wanted to implement, i.e. to collect
> >> all the flags that OVS really uses and clear/copy only these flags.
> >>
> >> But then I started to think about 'ring' ports and that we might send
> >> mbufs with incorrect flags set after the packet modification to the
> >> external application.  This doesn't sound good.  Because if OVS doesn't
> >> use them doesn't mean that other applications doesn't.  So, I've end up
> >> with the current logic with clearing everything except the memory layout
> >> flags.
> >>
> >> Does it make sense?  What do you think?
> >
> > Before sending a packet through a dpdk ring, OVS will touch the data
> > and update the relevant flags as far as it is concerned.
> >
> > The application can read/touch those mbuf flags as long as it complies
> > with the DPDK APIs, this concerns both the flags that OVS is aware of,
> > and the rest.
> > So when getting this mbuf back, the flags should be valid.
> >
> > After this, OVS can do what it wants on the packet, it will only touch
> > the flags it understands.
> >
> > What am I missing?
>
> I agree that OVS itself will work OK by only considering flags it
> really uses.  I'm concerned about the second application that receives
> mbuf from the OVS via ring port.  For example, I see that ixgbe driver
> almost unconditionally parses vlans and sets PKT_RX_VLAN along with
> mbuf->vlan_tci.  If OVS will not clear this flag while sending to

- Well, as I said, if OVS touches the data (pops a vlan), it must
update the flags (PKT_RX_VLAN).
This is overkill if the mbuf does not leave OVS, so it could be
cleared unconditionally before jumping in the ring.


- What kind of applications can read those rings?
Are those dpdk secondary applications?
Asking, since we know that the multiprocess stuff is not really that
robust and/or usable with OVS.


-- 
David Marchand