Hi everyone,

I agree with opinion #3 as well. It allows us to keep 0 as “unknown" (i.e., not 
set by the driver), and we can specify ~0 as “Not Applicable” (typically the 
case for virtual links) and change format_vnet_hw_interface_link_speed 
accordingly.

Best regards,

Mohammed

> On 18 Jan 2021, at 12:06, Benoit Ganne (bganne) via lists.fd.io 
> <bganne=cisco....@lists.fd.io> wrote:
> 
> Hi Matt,
> 
> I am adding the list so that maybe VPP DPDK plugin users/maintainers can 
> chime in.
> In my opinion #3 setting link speed to ~0 makes sense as VPP usually use ~0 
> as "invalid".
> 
> The original issue I attempted to fix in DPDK was that the Mellanox DPDK 
> driver was not able to return link status in Azure because it refused to 
> return link status if it could not determine link speed. My original proposed 
> change in DPDK was just for the Mellanox DPDK driver to return link status 
> anyway but not link speed in that case (as eg. Intel drivers do). It ended up 
> being a bit more complicated in the end 😊
> 
> Best
> ben
> 
>> -----Original Message-----
>> From: Matthew Smith <mgsm...@netgate.com>
>> Sent: vendredi 15 janvier 2021 21:12
>> To: Benoit Ganne (bganne) <bga...@cisco.com>
>> Cc: Jim Thompson <j...@netgate.com>
>> Subject: DPDK change in link speed convention
>> 
>> 
>> Hi Benoit,
>> 
>> i saw a change to DPDK which listed "Suggested-by: Benoit Ganne
>> <bga...@cisco.com <mailto:bga...@cisco.com> >" -
>> -
>> https://github.com/DPDK/dpdk/commit/810b17d116f03783843d23ac900a3794675f66
>> 16#diff-2e1c01c3a61689ba8e51c0cf41d4d8153870532b8d64ea0847dff7a169e54bef.
>> 
>> Due to this change, it seems that rte_eth_link_get_nowait() can now return
>> ~0 for ports where the link speed is unknown or for virtual links. Along
>> with another change
>> (https://github.com/DPDK/dpdk/commit/b415b7a06856b148ace29ffcc6e9740a12b9e
>> c33#diff-c943f71001a82a273432fb087f7cd461d9666ee5cfd58a0b1b2b93b68d9f6234)
>> this has resulted in VPP reporting the link speed of DPDK virtio
>> interfaces as 4294966296 kbps. This is because the VPP DPDK plugin calls
>> vnet_hw_interface_set_link_speed() with the link speed value retrieved by
>> rte_eth_link_get_nowait() multiplied by 1000 to convert Mbps to kbps. When
>> rte_eth_link_get_nowait() returns a link speed of ~0, multiplying it by
>> 1000 overflows a u32 and the value that is set on the vnet_hw_interface_t
>> is 4294966296.
>> 
>> It seems like something different should happen in the VPP DPDK plugin
>> when the link speed is reported by DPDK as ~0. Maybe one of these options
>> would be good:
>> 
>> 1. Don't call vnet_hw_interface_set_link_speed() at all in this case. If
>> the current link speed is being reported as "unknown", maybe whatever
>> value is set on the VPP hw interface should be left as it is.
>> 2. Call vnet_hw_interface_set_link_speed() with a link speed of 0. The
>> default link speed value of a new vnet_hw_interface_t is 0, so 0 could be
>> viewed as the de facto VPP version of "unknown".
>> 3. Call vnet_hw_interface_set_link_speed() with a link speed of ~0 rather
>> than (~0 * 1000) as is currently done. And agree/document that this value
>> means "unknown" in VPP.
>> 
>> Since the DPDK commit that announced this change had a Suggested-by header
>> that mentioned you, I wanted to find out if you had thoughts on how this
>> should be handled or if you already had some work in progress to deal with
>> this.
>> 
>> Thanks!
>> -Matt
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18534): https://lists.fd.io/g/vpp-dev/message/18534
Mute This Topic: https://lists.fd.io/mt/79920343/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to