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
> 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
>> Sent: vendredi 15 janvier 2021 21:12
>> To: Benoit Ganne (bganne)
>> Cc: Jim Thompson
>> Subject: DPDK change in link speed convention
>>
>>
>> Hi Benoit,
>>
>> i saw a change to DPDK which listed "Suggested-by: Benoit Ganne
>> 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]
-=-=-=-=-=-=-=-=-=-=-=-
