Regards _Sugesh
> -----Original Message----- > From: Yuanhan Liu [mailto:[email protected]] > Sent: Monday, September 11, 2017 11:23 AM > To: Chandran, Sugesh <[email protected]> > Cc: [email protected] > Subject: Re: [ovs-dev] [PATCH v2 0/8] OVS-DPDK flow offload with rte_flow > > On Mon, Sep 11, 2017 at 10:00:06AM +0000, Chandran, Sugesh wrote: > > > > In our implementation we have a feature discovery at the OVS init. > > > > It will > > > also populate the OVSDB to expose the device capability to higher > > > management layers. The new table introduced in OVSDB is like below. > > > > > > The solution I want to go, however, is different though. I was > > > thinking to introduce few DPDK rte_flow APIs and structs to define > > > the NIC flow capabilities. > > [Sugesh] technically rte_flow is for flow programming and not for device > capabilities. > > Not really. rte_flow is just a framework, it needs the underlaying NIC to do > the real thing. Each NIC has different limitations (we have seen quite few of > them). Thus, we need something like this. > > If you think this way: device capabilities regarding to flow, it may make more > sense to you :) [Sugesh] For our use case , we are have more features to be considered/wanted to expose. Those are not really a 'flow' attribute. Instead they are the device properties that necessary to decide a flow is offload'able/not. > > > Again if DPDK can have such API in rte_flow. I think it should be fine. > > Good! I will make a proposal to DPDK for v18.02 then. [Sugesh] Also its worth looking at the new port representor model in DPDK. The reason being, we are planning to propose an extension to it for exposing device capabilities for our use case :) > > > > > 4) AFAIK, these hardware programmability for a NIC/not for a specific > port. > > > i.e the FDIR/RSS hash configuration are device specific. This will > > > be an issue if a NIC shared between kernel and DPDK drivers? > > > > > > That might be NIC specific. What do you mean by sharing between > > > kernel and DPDK? In most NICs I'm aware of, it's requried to unbind > > > the kernel driver first. Thus, it won't be shared. For Mellanox, the > > > control unit is based on queues, thus it could be shared correctly. > > [Sugesh] What I meant by that is, consider a case of NIC with 4*10G ports. > > 2 ports bound to DPDK and 2 ports to kernel. > > I see. > > > If I remember correctly XL710 NIC can support total 8k exact match > > flow entries in its Flow director. Similarly some other resources are also > shared across all the ports in the NIC. > > Now how these resources are properly managed between Kernel and > DPDK. > > Honestly, I don't know. We may need testings/investigations. [Sugesh] yes. > > > I agree that Mellanox NICs this should be fine, but not sure if it > > work on all the NICs out there. This will make adverse effect on each other > when making changes to any global configuration. > > For sure I agree we should make it work on as many nics as possible. > And I think that's what this patchset trying to do. [Sugesh] Sure, Thank you! > > --yliu _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
