On 25.11.2019 12:23, Ilya Maximets wrote: > On 24.11.2019 21:38, David Marchand wrote: >> On Fri, Nov 22, 2019 at 3:04 PM Ilya Maximets <i.maxim...@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). > > I don't think that DPDK API requires that anyhow. Otherwise, DPDK
s/Otherwise/Contrariwise/ > must ensure that RX flags are valid after receiving mbuf from the > DPDK port, but that is not true for ring pmd. > >> This is overkill if the mbuf does not leave OVS, so it could be >> cleared unconditionally before jumping in the ring. > > That is unclear why we should act differently for ring ports if we > could just clear everything always and there is already generic > API for that (dp_packet_reset_offload). > >> - What kind of applications can read those rings? >> Are those dpdk secondary applications? > > I think so. > >> Asking, since we know that the multiprocess stuff is not really that >> robust and/or usable with OVS. > > I had an intention to deprecate ring ports in OVS, firstly because of > the poor level of support and testing, but I'm not sure if anyone uses > them or not. I could prepare the deprecation patch to collect some > opinions. > > BTW, I'm not sure if I ever used ring ports in OVS, maybe once for ivshmem. > And I'm not sure if anyone tests them any regularly (this is highly > unlikely since ring tests are not included even in VSPERF). > > Best regards, Ilya Maximets. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
