Matias Elo(matiaselo) replied on github web page:
platform/linux-generic/pktio/dpdk.c
line 39
@@ -1135,6 +1135,13 @@ static void dpdk_init_capability(pktio_entry_t
*pktio_entry,
rte_eth_dev_info_get(pkt_dpdk->port_id, dev_info);
capa->max_input_queues = RTE_MIN(dev_info->max_rx_queues,
PKTIO_MAX_QUEUES);
+
+ /* ixgbe devices support only 16 rx queues in RSS mode */
+ if (!strncmp(dev_info->driver_name, IXGBE_DRV_NAME,
+ strlen(IXGBE_DRV_NAME)))
+ capa->max_input_queues = RTE_MIN((unsigned)16,
+ capa->max_input_queues);
+
Comment:
@lumag That would be the best solution but I don't see it happening anytime
soon. The number of rx queues returned by rte_eth_dev_info_get() is in
principle correct. Here the limiting factor is RSS capability and as far as I
can see there is no way to query this information.
> Matias Elo(matiaselo) wrote:
> I'm not sure I got your point but anyway dev_info is type 'struct
> rte_eth_dev_info' and comes from dpdk, so nothing can be added there.
>
> As @lumag noted this fix is required because of a dpdk defect. With ixgbe
> drivers rte_eth_dev_info_get() returns a max_rx_queues value which is not
> valid (at least when using RSS). This is the only driver a have observer this
> issue with.
>
> The number 16 is explained in the comment line (1139) just above.
>> Matias Elo(matiaselo) wrote:
>> @Bill-Fischofer-Linaro Yes, the application has to request at least
>> 'min_rx_burst' packets but it may receive less.
>>> Matias Elo(matiaselo) wrote:
>>> @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_r149936718
updated_at 2017-11-09 11:31:03
