[PATCH v1] linux-gen: dpdk: misc fixes #2230
Conversation
DPDK receive burst size must be divisible by 8 to work with any driver, so increase minimum RX burst size to 8. Signed-off-by: Matias Elo <matias.elo@nokia.com>
Trying to receive or transmit packets after a DPDK device has been stopped is not allowed by DPDK. Fix this by moving rte_eth_dev_stop() to odp_pktio_close(). rte_eth_dev_stop() has to be called also inside odp_pktio_start() to enable reconfiguration. Signed-off-by: Matias Elo <matias.elo@nokia.com>
odpbuild
changed the title
| static int dpdk_stop(pktio_entry_t *pktio_entry) | ||
| static int dpdk_stop(pktio_entry_t *pktio_entry ODP_UNUSED) | ||
| { | ||
| rte_eth_dev_stop(pkt_priv(pktio_entry)->port_id); |
There was a problem hiding this comment.
I am not sure this is the right approach.
The generic packet i/o code maintains the logical pktio state and already tries to ensure that the device level TX and RX routines are not called when the pktio is in the stopped state. Maybe the real problem is that the interface between the generic pktio code and the device level code is not clear enough and not adhered to by the generic code.
The generic pktio code seems to be racy with respect to maintaining and checking the pktio state. _pktio_stop() sets the pktio state to stopped/stop_pending only "after" it has called the device specific stop function. TX and RX routines may thus not see the state change early enough and call the device specific TX and RX routines when the device specific stop has already been done, which presumably caused the crash mentioned in the commit title. Furthermore, the state variable is not an atomic sync variable used with proper memory ordering, so just moving the write to it in _pktio_stop() would not be enough.
I think the common code should be fixed.
There was a problem hiding this comment.
Yeah, the packet IO state maintenance, or lack of it, is the culprit behind this issue. This commit is just a quick fix/workaround to enable performance testing. Fixing the pktio state maintenance is a bigger task and we need to consider how much overhead is accepted for the fast path functions.
2 participants
No description provided.