On Wed, Apr 8, 2020 at 11:32 PM Lazuardi Nasution <[email protected]> wrote: > > Hi Greg, > > Thank you for your suggestion. But anyway, why don't you suggest No. 1? > > In term of using suggested No. 2 with MLX5 PMD, is representor port still > needed? I assume that there is no need to communicate between PF and VF. > Let's say, PF is used for Ceph storage and other kernel based (non-DPDK) > services, VF is used for OVS-DPDK. > > Best regards, > > On Wed, Apr 8, 2020, 22:24 Gregory Rose <[email protected]> wrote: >> >> >> On 4/8/2020 5:50 AM, Lazuardi Nasution wrote: >> > Hi, >> > >> > I'm looking for best practice or experience on running OVS-DPDK and other >> > kernel based applications with the same interface especially with MLX5 PMD. >> > As long as I know, one of both must use VF and the other use PF >> > since kernel and DPDK cannot bind to same interface. Which one of following >> > is possible and better? >> > >> > 1. OVS-DPDK bind to PF and kernel bind to VF >> > 2. OVS-DPDK bind to VF and kernel bind to PF You can use the dpdk rte_flow isolate mode, if DPDK bind to PF, but PF can forward the packet to kernel too. OVS does not support this but it is easy to implement.
>> > If it is better (or the only possible) to use No. 2, what version of OVS >> > and DPDK support VF binding? Should I bind to kernel created VF directly or >> > it's representor? >> >> If you use option 2 then the Linux kernel has PCI-e primitives that >> support the allocation of the VF resources, including number of VFs, >> their permissions and settings of any offload capabilities that the VFs >> might have. >> >> - Greg >> > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss -- Best regards, Tonghao _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
