> Subject: Re: [PATCH v9 05/12] net/nfp: add flower PF setup logic > > I don't understand your logic fully, > but I understand you need special code to make your hardware work with > OvS, > meaning: > - OvS must have a special handling for your HW > - other applications won't work > Tell me I misunderstand, > but I feel we should not accept this patch, there is probably a better way to > manage the specific of your HW.
OvS need not do anything special handling for our HW. Other applications won't work -- Sorry I don't understand your mean at this point. > You said "NFP PMD can work with up to 8 ports on the same PF device." > Let's imagine you have 8 ports for 1 PF device. > Do you allocate 8 ethdev ports? > If yes, then each ethdev should do the internal work, and nothing is needed > at application level. No, we still just create 1 PF vNIC to handle the feedback traffic. Of course we will 8 representor port for physical port. > 21/09/2022 04:50, Chaoyong He: > > > On 9/15/2022 11:44 AM, Chaoyong He wrote: > > > Hi Chaoyong, > > > > > > Again, similar comment to previous versions, what I understand is > > > this new flower FW supports HW flow filter and intended use case is > > > for OvS HW acceleration. > > > But is DPDK driver need to know OvS data structures, like "struct > > > dp_packet", can it be transparent to application, I am sure there > > > are other devices offloading some OvS task to HW. > > > > > > @Ian, @David, > > > > > > Can you please comment on above usage, do you guys see any way to > > > escape from OvS specific code in the driver? > > > > Firstly, I'll explain why we must include some OvS specific code in the > > driver. > > If we don't set the `pkt->source = 3`, the OvS will coredump like this: > > ``` > > (gdb) bt > > #0 0x00007fe1d48fd387 in raise () from /lib64/libc.so.6 > > #1 0x00007fe1d48fea78 in abort () from /lib64/libc.so.6 > > #2 0x00007fe1d493ff67 in __libc_message () from /lib64/libc.so.6 > > #3 0x00007fe1d4948329 in _int_free () from /lib64/libc.so.6 > > #4 0x000000000049c006 in dp_packet_uninit (b=0x1f262db80) at > > lib/dp-packet.c:135 > > #5 0x000000000061440a in dp_packet_delete (b=0x1f262db80) at > > lib/dp-packet.h:261 > > #6 0x0000000000619aa0 in dpdk_copy_batch_to_mbuf > (netdev=0x1f0a04a80, > > batch=0x7fe1b40050c0) at lib/netdev-dpdk.c:274 > > #7 0x0000000000619b46 in netdev_dpdk_common_send > (netdev=0x1f0a04a80, > > batch=0x7fe1b40050c0, stats=0x7fe1be7321f0) at > > #8 0x000000000061a0ba in netdev_dpdk_eth_send (netdev=0x1f0a04a80, > > qid=0, batch=0x7fe1b40050c0, concurrent_txq=true) > > #9 0x00000000004fbd10 in netdev_send (netdev=0x1f0a04a80, qid=0, > > batch=0x7fe1b40050c0, concurrent_txq=true) at lib/n > > #10 0x00000000004aa663 in dp_netdev_pmd_flush_output_on_port > > (pmd=0x7fe1be735010, p=0x7fe1b4005090) at lib/dpif-netde > > #11 0x00000000004aa85d in dp_netdev_pmd_flush_output_packets > > (pmd=0x7fe1be735010, force=false) at lib/dpif-netdev.c:5 > > #12 0x00000000004aaaef in dp_netdev_process_rxq_port > > (pmd=0x7fe1be735010, rxq=0x16f3f80, port_no=3) at lib/dpif-netde > > #13 0x00000000004af17a in pmd_thread_main (f_=0x7fe1be735010) at > > lib/dpif-netdev.c:6958 > > #14 0x000000000057da80 in ovsthread_wrapper (aux_=0x1608b30) at > > lib/ovs-thread.c:422 > > #15 0x00007fe1d51a6ea5 in start_thread () from /lib64/libpthread.so.0 > > #16 0x00007fe1d49c5b0d in clone () from /lib64/libc.so.6 ``` The logic > > in function `dp_packet_delete()` run into the wrong branch. > > > > Then, why just our PMD need do this, and other PMDs don't? > > Generally, it's greatly dependent on the hardware. > > > > The Netronome's Network Flow Processor 4xxx (NFP-4xxx) card is the > target card of these series patches. > > Which only has one PF but has 2 physical ports, and the NFP PMD can work > with up to 8 ports on the same PF device. > > Other PMDs hardware seems all 'one PF <--> one physical port'. > > > > For the use case of OvS, we should add the representor port of 'physical > port' to the bridge, not the representor port of PF like other PMDs. > > > > We use a two-layer poll mode architecture. (Other PMDs are simple poll > > mode architecture) In the RX direction: > > 1. When the physical port or vf receives pkts, the firmware will prepend a > meta-data(indicating the input port) into the pkt. > > 2. We use the PF vNIC as a multiplexer, which keeps polling pkts from the > firmware. > > 3. The PF vNIC will parse the meta-data, and enqueue the pkt into the > corresponding rte_ring of the representor port of physical port or vf. > > 4. The OVS will polling pkts from the RX function of representor port, which > dequeue pkts from the rte_ring. > > In the TX direction: > > 1. The OVS send the pkts from the TX functions of representor port. > > 2. The representor port will prepend a meta-data(indicating the output > port) into the pkt and send the pkt to firmware through the queue 0 of PF > vNIC. > > 3. The firmware will parse the meta-data, and forward the pkt to the > corresponding physical port or vf. > > > > So the OvS won't create the mempool for us and we must create it > ourselves for the PF vNIC to use. > > > > Hopefully, I explained the things clearly. Thanks. > >
