On 29 January 2016 at 04:03, Ilya Maximets <i.maxim...@samsung.com> wrote:
> Hi.
>
> On 29.01.2016 04:02, Daniele Di Proietto wrote:
>> Hi guys,
>>
>> Sorry for resurrecting this thread, but I think we should reconsider
>> this patch at this point.
>>
>> Let me explain: I'm still perfectly happy with the fix we applied,
>> e4e74c3a2b9a("dpif-netdev: Purge all ukeys when reconfigure pmd."),
>> it is necessary to properly collect stats and it works perfectly
>> when reconfiguring pmd threads.
>>
>> I'm revisiting this, because I'm not that comfortable anymore assuming
>> that packets with the exact same flow have to come in from the
>> same queue. Here's a couple of scenarios:
>>
>> - With vhost-user multi queue, I'm not sure that anything prevents a
>> guest from sending the same flow to different queues.
>
> Nothing prevents. That is true. But this situation isn't really clear.
> Can you imagine situation where normal application in normal mode
> sends same flow to different queues and expects no issues?
>
>> - We've encountered the same bug in dpif-netdev when adding/removing
>> ports. We fixed it by never moving the queues from the original
>> pmd thread, which makes sense, but that's just an example
>> - At some point it would be nice to reassign queues among pmd threads
>> without deleting the megaflow cache.
>
> I agree that this two scenarios can be useful. I want to implement
> some kind of scheduler for pmd threads to manage port/rxqs assignment.
> In this case ability to reassign queues without destroying of threads
> will be very nice.
I was hoping Alex might chime in on-list as he spent a bit more time
thinking about this than me, but the patch seems reasonable to me.
Longer term I think there are various things we can do to improve
revalidation in the userspace datapath, but this change doesn't really
make a difference for the direction of that work.
For the actual patch, I think typically we would mix in values using
something like hash_2words(ufid->u32[0], pmd_id) rather than addition.
Ilya, do you mind resending? I can review/merge it unless anyone else
has thoughts/objections.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
