On 24.11.2019 21:38, David Marchand wrote: > On Fri, Nov 22, 2019 at 3:04 PM Ilya Maximets <[email protected]> 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 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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
