09/09/2022 14:13, Ferruh Yigit: > On 9/9/2022 3:36 AM, Chaoyong He wrote: > >> On 9/8/2022 9:44 AM, Chaoyong He wrote: > >>> Adds the vNIC initialization logic for the flower PF vNIC. The flower > >>> firmware exposes this vNIC for the purposes of fallback traffic in the > >>> switchdev use-case. > >>> > >>> Adds minimal dev_ops for this PF device. Because the device is being > >>> exposed externally to DPDK it should also be configured using DPDK > >>> helpers like rte_eth_configure(). For these helpers to work the flower > >>> logic needs to implements a minimal set of dev_ops. > >>> > >>> Signed-off-by: Chaoyong He <chaoyong...@corigine.com> > >>> Reviewed-by: Niklas Söderlund <niklas.soderl...@corigine.com> > >>> --- > >>> drivers/net/nfp/flower/nfp_flower.c | 398 > >> ++++++++++++++++++++++++- > >>> drivers/net/nfp/flower/nfp_flower.h | 6 + > >>> drivers/net/nfp/flower/nfp_flower_ovs_compat.h | 37 +++ > >> > >> Can you please detail why OVS specific header is required? Having > >> application > >> specific code in PMD can be sign of some design issue, that is why can you > >> please explain more what it does? > >> > > > > Basically, there exist two layers polling mode to move a pkt from firmware > > to OVS. > > > > When our card using flower application firmware receive pkt and find the > > pkt can't be offloaded, > > it will record the input port in a place of the pkt, we call it metadata. > > > > There exist a rte_ring for each representor port. > > > > We use the pf device as a multiplexer, which keeps polling pkts from the > > firmware. > > Based on the metadata, it will enqueue the pkt into the rte_ring of the > > corresponding representor port. > > > > On the OVS side, it will keeps try to dequeue the pkt from the rte_ring of > > the representor port. > > Once it gets the pkt, the OVS will go its logic and treat the pkt as > > `struct dp_packet`. > > > > So we copy the definition of `struct dp_packet` from OVS to prevent the > > coredump caused by memory read/write out of range. > > > > Another possible way is defining a big enough mbuf_priv_len using macro to > > prevent this structure definition from OVS. > > Is this the right way? > > > > Thanks for clarification. > > PMD is creating a mempool to hold 'struct dp_packet', that is why it is > duplicating OvS 'struct dp_packet' struct definition to DPDK. > > But many PMDs are used with OvS, why only nfp need to duplicate the > struct or create OvS specific mempool? > Having application specific code in driver looks wrong anyway.
+1 to be application agnostic
