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 :)
> 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.
> > > 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.
> 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.
--yliu
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
