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 files if needed. I don't think that splitting now can limit any future plans to implement a multi-threaded offload. What do you think? > -----Original Message----- > From: Ilya Maximets <[email protected]> > Sent: Wednesday, February 20, 2019 7:06 PM > To: Ophir Munk <[email protected]>; [email protected] > Cc: Ian Stokes <[email protected]>; Olga Shern <[email protected]>; > Kevin Traynor <[email protected]>; Asaf Penso <[email protected]>; > Roni Bar Yanai <[email protected]>; Shahaf Shuler > <[email protected]>; Flavio Leitner <[email protected]>; Finn > Christensen <[email protected]> > Subject: Re: [PATCH v1 0/3] Move offloading-code into a new file > > 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 locks remains in netdev-dpdk. > While we have a single thread that handles all the offloading in dpif-netdev > it's not an issue. But I'm wondering, what will happen if we'll decide to use > offload API concurrently ? What will happen if we'll need to perform few > operations on the same device atomically. > > I'm not sure if we'll need this or not. Maybe someone has ideas or knows > such scenarios that will require atomicity ? > Is there need of changing current single-thread model to multi-thread ? > > In fact that some NICs are not fast enough in updating flow tables (like cxgbe > that could take up to 10 seconds), having multiple offloading threads might > be a good idea. > > Best regards, Ilya Maximets. > > > On 18.02.2019 19:16, Ophir Munk wrote: > > 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 > > reasons: > > 1. This series does not change the existing OVS code flows/logic on master > branch. > > OVS functionality is the same before and after this series. > > 2. The separation is essential for new offloading-code development > > without interfering with the rest of OVS development. > > 3. Vice versa: it is essential that while developing offloading-code - > > to be able to frequently rebase on top of master branch. > > 4. The OVS-kernel is practicing the same approach. Please note the file > lib/netdev-tc-offloads.c. > > > > Based on the points mentioned above we kindly ask that the series will > > be applied on top of the master branch. > > > > Ophir Munk (1): > > netdev-rte-offloads: Rename netdev_dpdk_* functions > > > > Roni Bar Yanai (2): > > netdev-dpdk: Expose flow creation/destruction calls > > netdev-dpdk: Move offloading-code to a new file > > > > lib/automake.mk | 4 +- > > lib/netdev-dpdk.c | 764 > > ++------------------------------------------- > > lib/netdev-dpdk.h | 14 + > > lib/netdev-rte-offloads.c | 778 > > ++++++++++++++++++++++++++++++++++++++++++++++ > > lib/netdev-rte-offloads.h | 39 +++ > > 5 files changed, 855 insertions(+), 744 deletions(-) create mode > > 100644 lib/netdev-rte-offloads.c create mode 100644 > > lib/netdev-rte-offloads.h > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
