On 15-Nov-18 7:02 PM, Lam, Tiago wrote:
Hi guys,OvS-DPDK has recently had small a change that changed the data room available in an mbuf (commit dfaf00e in OvS). This seems to have had the consequence of breaking the initialisation of eth_af_packets interfaces, when using default values ("options:dpdk- devargs=eth_af_packet0,iface=enp61s0f3"). After investigating, what seems to be happening is that the eth_af_packet dev expects an available space of "2048B - TPACKET2_HDRLEN + sizeof(struct sockaddr_ll) = 2016B" to be available in the data room of each mbuf. Previous to the above commit, OvS would allocate some extra space, and this would mean there would be enough room for the checks performed in eth_rx_queue_setup() and eth_dev_mtu_set() in rte_eth_af_packet.c. However, with the recent commit that isn't the case anymore, and without that extra space the first check in eth_rx_queue_setup() will now be hit and setup of a eth_af_packet interface fails. What I'm trying to understand here is, the logic behind setting a default 'framesz' of 2048B and it being hardcoded (instead of being based on the underlying MTU of the interface, or the mbuf data room directly). The documentation in [1] for mmap() and setting up buffer rings mentions the exact same values (tp_block_size=4096,tp_frame_size=2048), which seem to have been introduced on the first commit, back in 2014. The only constraint for the framesize, it seems, its that it fits inside the blocksize (i.e. doesn't span multiple blocksizes), and is aligned to TPACKET_ALIGNMENT.
I think the reason is no one bothered to do it properly (same with detecting NUMA node locality for AF_PACKET interfaces - they all report as being on socket 0, even though it's possible to get this info from sysfs and set it correctly).
-- Thanks, Anatoly
