Matias Elo(matiaselo) replied on github web page: platform/linux-generic/pktio/dpdk.c line 70 @@ -1372,10 +1382,10 @@ static int dpdk_recv(pktio_entry_t *pktio_entry, int index, if (!pkt_dpdk->lockless_rx) odp_ticketlock_lock(&pkt_dpdk->rx_lock[index]); /** - * ixgbe_pmd has a minimum supported RX burst size ('min_rx_burst'). If - * 'num' < 'min_rx_burst', 'min_rx_burst' is used as rte_eth_rx_burst() - * argument and the possibly received extra packets are cached for the - * next dpdk_recv_queue() call to use. + * ixgbe and i40e drivers have a minimum supported RX burst size
Comment: @nagarahalli This dpdk driver "feature" can be completely hidden from odp applications (and it already is), so I don't support adding a new device capability parameter. This would make writing simple applications more complex. E.g. an application wouldn't be able to receive one packet at a time anymore. > Bill Fischofer(Bill-Fischofer-Linaro) wrote: > Again, shouldn't this sort of configuration be a field in the `dev_info` > struct rather than having to be special-cased for each driver? Also, must 16 > be a "magic number" here? >> Dmitry Eremin-Solenikov(lumag) wrote: >> It looks like this should be fixed inside DPDK rather than here. >>> Bill Fischofer(Bill-Fischofer-Linaro) wrote: >>> Presumably these drivers have a way of flushing short bursts? If the >>> `min_rx_burst` is 4 and the other side sends an odd number of packets, >>> presumably the receiver application isn't left hanging forever waiting for >>> the rest of a burst that will never arrive? >>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote: >>>> Wouldn't it be simpler (and more extensible) to have `min_rx_burst` as a >>>> field in the `dev_info` struct? >>>>> nagarahalli wrote >>>>> 'min_rx_burst' should be added to the capability as it is a restriction >>>>> from the device. The application should adjust the 'num' according to the >>>>> capability it reads from the pkt I/O. https://github.com/Linaro/odp/pull/287#discussion_r149895991 updated_at 2017-11-09 08:51:10