On 02/08/2018 12:19 PM, Ilya Maximets wrote:
>> 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
> I'm sorry, but I see no meeting minutes for the latest OVS-DPDK sync call.

As per other mail - just haven't had time to send yet. Will send shortly.

> 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 think it's a pretty clean revert. I've reviewed it and tested out
things like MTU reconfig, sharing, not sharing mempools etc.

It is not clear that a few fixes on branch-2.9 will make the per port
mempool ok to use. It seems strange that OVS 2.9 would go out with
backwards compatibility broken but with a promise it will try to be
fixed in the future on the branch with *new* memory model development.
AFAIK, there is no proposal for what the new memory model would look like.

> 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?

Good point about possible difference in branch-2.9 vs. master. I was
thinking about branch-2.9 only wrt revert. If there is a thought that
mempool per port can be fixed or could be useful as part of a user
choice etc., then maybe it would make sense to not revert on master,
subject to more development of a better solution.

> Best regards, Ilya Maximets.

It's not perfect, but we've replaced something that has been working
with little or no complaints for 4 years with something that breaks
backwards compatibility for some users, and some (like Jan) possibly
can't even use OVS at all like this. I think it makes sense to revert it
for OVS 2.9 and rethink how to make memory scale - maybe that will be
per port memory pools with fixes, maybe some hybrid scheme, maybe some
sort of user intervention to choose scheme or memory sizes.


dev mailing list

Reply via email to