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
