Hi Ilya,
On 10/01/2019 11:51, Ilya Maximets wrote:
> On 09.01.2019 21:05, Tiago Lam wrote:
>> From: Mark Kavanagh <[email protected]>
>>
[snip]
>>
>> @@ -971,6 +1002,24 @@ dpdk_eth_dev_port_config(struct netdev_dpdk *dev, int
>> n_rxq, int n_txq)
>> }
>> }
>>
>> + /* Multi-segment-mbuf-specific setup. */
>> + if (dpdk_multi_segment_mbufs) {
>> + if (info.tx_offload_capa & DEV_TX_OFFLOAD_MULTI_SEGS) {
>> + /* Enable multi-seg mbufs. DPDK PMDs typically attempt to use
>> + * simple or vectorized transmit functions, neither of which are
>> + * compatible with multi-segment mbufs. */
>> + conf.txmode.offloads |= DEV_TX_OFFLOAD_MULTI_SEGS;
>> + } else {
>> + VLOG_WARN("Interface %s doesn't support multi-segment mbufs",
>> + dev->up.name);
>> + conf.txmode.offloads &= ~DEV_TX_OFFLOAD_MULTI_SEGS;
>
> Simple warning is not enough.
> There are few PMDs that does not support segmented packets and does not
> expect them. Sending segmented packets to such ports could cause a crash,
> memory leaks or any other unexpected behaviour and they will simply not
> work, at first.
> We need a fallback solution for this case.
>
> Best regards, Ilya Maximets.
>
Thanks, that makes sense. I guess we can have the fallback of failing to
initialize the device as a last resort, and point out that such an
interface can't be used with multi-segs. As discussed in yesterday's
community call, we plan to mark this experimental at first to understand
such cases.
An aside, as part of the TSO work I've started to integrate with
`rte_eth_tx_prepare()` in DPDK. I can see in the code that it wouldn't
help in this case, but I would expect that such cases would be handled
by this function in the future.
What do you think?
Thanks,
Tiago.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
