> -Original Message-
> From: Flavio Leitner
> Sent: Thursday, February 21, 2019 1:40 PM
> To: Ophir Munk
> Cc: Ilya Maximets ; ovs-dev@openvswitch.org;
> Ian Stokes ; Olga Shern ;
> Kevin Traynor ; Asaf Penso ;
> Roni Bar Yanai ; Shahaf Shuler
> ; Finn Christensen
> Subject: Re: [PATC
On Wed, Feb 20, 2019 at 10:25:45PM +, Ophir Munk wrote:
> If we wanted to switch to a multi-threaded offload model today- we could have
> done it in two steps:
> 1. Implement a multi-threaded model on current master branch.
> 2. Do the split.
>
> The two steps seem independent. The split i
If we wanted to switch to a multi-threaded offload model today- we could have
done it in two steps:
1. Implement a multi-threaded model on current master branch.
2. Do the split.
The two steps seem independent. The split is rather technical and there are
ways to share/pass locks between two f
Ilya, this is what I think.
I think there are two points here. First is the atomicity of offloading flows
and the second is concurrency in offloading on dpif.
Regarding the first point, at this point flows are logically atomic, so if for
example you are offloading with two threads the lock
Is req
One general concern to think about:
This code split introduces few helper functions that resides in netdev-dpdk
and calls dpdk API by the requests of other modules (netdev-rte-offloads).
This strategy will not allow us to lock the device for performing several
operations atomically because all the
Hardware offloading-code is moved to a new file called
netdev-rte-offloads.c. The original offloading-code is copied as is
from the netdev-dpdk.c file to the new file where future
offloading-code should be added as well.
This series is essential for offloading-code development for the following
re
