[ovs-dev] OVS DPDK Mempool revert

[Stokes, Ian]

> -----Original Message-----
> From: Ilya Maximets [mailto:i.maximets at samsung.com]
> Sent: Thursday, February 8, 2018 12:19 PM
> To: ovs-dev at openvswitch.org; Stokes, Ian <ian.stokes at intel.com>
> Cc: 'Jan Scheurich' <jan.scheurich at ericsson.com>; Kevin Traynor
> <ktraynor at redhat.com>; Flavio Leitner <fbl at redhat.com>; Aaron Conole
> <aconole at redhat.com>; Loftus, Ciara <ciara.loftus at intel.com>; Kavanagh,
> Mark B <mark.b.kavanagh at intel.com>; Ben Pfaff <blp at ovn.org>
> Subject: Re: [ovs-dev] OVS DPDK Mempool revert
> 
> > Hi all,
> >
> > As discussed on the OVS-DPDK community call, I've manually reverted the
> per port mempool changes in OVS-DPDK on a branch on my own git hub. This
> had to be re-introduced manually due to the number of commits and work
> that had went on top of the per port implementation.
> >
> > For testing people can access it from the link below:
> >
> > https://github.com/istokes/ovs/tree/mempool_revert
> >
> > If we are to revert this in time for OVS 2.9 there is a need for
> validation among the community to ensure that it does not break any
> features. I have validated most existing features with VSperf but I'm more
> interested in ensuring existing user test cases do not break with this
> revert.
> 
> I thought that we wanted to update the documentation for now with new
> memory requirements, prepare new mempool model for 2.10 and backport it to
> 2.9 if necessary., As mentioned here:
> 
> 	https://mail.openvswitch.org/pipermail/ovs-discuss/2018-
> January/046101.html

This was the agreement, however the feeling on yesterday's community call (And feel free to correct me) was that this causes a headache for user upgrading to 2.9.0, they then have to deal with the memory issue on a per port basis for 2.9.0, and then on a shared memory basis for 2.9.1. This isn't a trivial change for tem and the shared mempool option is preferred for 2.9.0 if possible.

> 
> I'm sorry, but I see no meeting minutes for the latest OVS-DPDK sync call.
> 
I don’t think they've been sent out yet. I just wanted to get ahead and flag this approach as I feel it's important to make everyone aware as soon as possible.

> In general, I think that temporary reverting of the current model looks
> not so pretty. Especially if we're going to almost revert this revertion
> in the future.
> 

I agree, it's not very pretty. But we're re-introducing shared memory in the future then I'd like it not to block upgrades to the 2.9.0 branch.

From the call it seems the preferred method is shared memory, to me it makes sense to revert now and build on top of it.

> Does you RFC patch intended for branch-2.9 only? In this case it may be
> acceptable. We'll continue working on current model for 2.10 to fix all
> the issues or implement some completely new model. And branch-2.9 will be
> left with shared mempool model forever. Did I understand correctly?

I hadn't thought of this option, just keeping the revert to the 2.9 branch specifically but not master.

Again it comes back to the starting point for our new solution, if shared memory is generally preferred by the community then it would make sense to revert and re-introduce the per port model in a less invasive manner so that they can co-exist.

This new model could be backported to 2.9.1 if required with the understanding that shared memory behavior is the default so as to maintain backwards compatibility.

Ian
> 
> Best regards, Ilya Maximets.