rx,tx: enable multi segment to support higher mtu #244
Conversation
| return errno_log(-ret, "rte_eth_dev_info_get"); | ||
|
|
||
| if (strcmp(info.driver_name, "net_tap") == 0) { | ||
| p->n_txq = RTE_MAX(p->n_txq, p->n_rxq); |
There was a problem hiding this comment.
This patch has nothing to do with the series about larger packets.
In any case, I am not following.
Why remove this part above?
With the previous code, if a user requests more rxq, this would result in unneeded txq, but I don't see a problem with this.
There was a problem hiding this comment.
I'll drop this patch for now.
In order to support receiving packets larger than 2048 bytes, we need to enable multi-segment rx and tx offload in the drivers. Enable RTE_ETH_RX_OFFLOAD_SCATTER and RTE_ETH_TX_OFFLOAD_MULTI_SEGS in the requested offload flags when configuring DPDK ports. Update the basic IP forward test to check we are indeed receiving 5000 bytes packets with a configured MTU of 9000 bytes. Suggested-by: David Marchand <[email protected]> Signed-off-by: Robin Jarry <[email protected]>
|
Just a note that accepting larger frames is fine, but there is nothing in grout atm for fragmenting in case of heterogenous mtu interfaces. |
|
yep, we don't even check for MTU when sending packets. |
|
Yes, that's part of what I had in mind when commenting. |
maxime-leroy
left a comment
maxime-leroy
left a comment
There was a problem hiding this comment.
We should be very careful on that.
Most of code doing operation on mbuf supposes there is only one segment, data are contiguous.
Most of time network header will be in first segment, but anyway to have safe code if we active mutli segs, you can not anymore present that all data are in the first segments.
|
Use of rte_pktmbuf_read would be the safest, but blindly adding checks would impact performance. If multiseg scares you, another approach is to allow bigger frames in the packet pool (for which there is no configuration knob atm). |
Of course, we can use jumbo mbuf to support jumbo packet. The side effect is increased memory consumption. Else it's to support multi segs. In this case, doing the check about multi segments when writing a mbuf or reading this one must be done. Of course, the side effect is an extra cost for cpu. Nothing is free, you must choose if you want to increase memory cpu cycles or cpu cost to support jumbo frames. Just enabling the feature without wondering if some operations done on muf are safe or not with multiseg is the perfect way to get crash. I am against this commit, It should not have been merged without answering properly about my point. Prove me that all operations are safe in grout with multi segments or else fix it. |
Operations aren't safe for sure. I don't have any specific preference. The only thing I want is for jumbo MTUs to work. We could use bigger MBUFs. Is there any downside to this besides high memory consumption? |
This commits will drop performance (at least > 10% au doigt mouillé). Don't have time to do the test. But by enabling scatter in rx and multi segment in tx, you use less performance function of driver for RX/TX (i.e. vector vs non vector). By using jumbo mbuf, you don't have the problem. I don't see any sideeffect, except the increaze of memory consumption. We should do the math to see if it's acceptable or not. Maybe an option --jumbo could be added at grout. To not force any one to have these big mbuf. At least, if we need multi segments, we should enable only when mtu is > mbuf headroom. To keep the best performance for standard mtu. |
3 participants
In order to support receiving packets larger than 2048 bytes, we need to enable multi-segment rx and tx offload in the drivers.
Enable RTE_ETH_RX_OFFLOAD_SCATTER and RTE_ETH_TX_OFFLOAD_MULTI_SEGS in the requested offload flags when configuring DPDK ports.
Update the basic IP forward test to check we are indeed receiving 5000 bytes packets with a configured MTU of 9000 bytes.
Suggested-by: David Marchand [email protected]