Hi From: Benoit Ganne (bganne) <bga...@cisco.com> > > From: Matan Azrad <ma...@mellanox.com> > > >> From: Benoît Ganne > >> mlx5 PMD refuses to update link state if link speed is defined but > >> status is down or if link speed is undefined but status is up, even > >> if the ioctl() succeeded. > >> This prevents application to detect link up/down event, especially > >> when the link speed is not correctly detected. > > > Do you use the wait option? Or no wait? > > We are using the no wait option.
I suggest to call again if failed for N retries time. > >> As link speed is nice to have whereas link status is mandatory for > >> operations, always update link state regardless of link speed. > >> The application can then check link speed if needs be. > > > Is it documented well? I didn't find doc\description says link speed > > is best effort. > > PMD cannot guess whether link speed is mandatory for the user or not.... > > I do not think it is documented and I suppose at the end of the day it > depends from the HW and configurations... > My commit message is misleading, my apologizes. What I meant was to let > the app decide whether it should retry or not, based on the data it gets. > Right now, the PMD *prevents* the app to get link state if the link speed is > undefined even if the app does not care about link speed. In mlx5 this is not the case, we have no one updated and second not - there are going together: You can see that we have 2 different system calls: 1 to get up\down and second to get link speed. If link speed doesn't appropriate to the link state it may say that something was changed between the calls and the link status we got from the first call is not correct anymore. In this case, we should call both calls again, that’s what we are doing in "nowait" option. If the user doesn't want "nowait" option, (means PMD is not allowed to take more time for response) he should call again when the callback failed in the time and retries manner the user prefers. > It makes an > assumption on behalf of the apps. Moreover, it seems to be one of the few > PMDs to make this assumption: at least the mlx4 PMD and the i40e PMD > does not seem to make this assumption. > This is a problem for our app (fd.io VPP) but I was also told about other apps > having the same issue too. > > > I think, at least you should update ethdev relevant API descriptions > > and get agreement from more PMD maintainers... > > I hope to get feedback 😊 it is precisely the goal of this. > > ben
