On Wed, 1 Jul 2020 23:13:13 +0100 Edward Cree wrote: > On 01/07/2020 20:03, Jakub Kicinski wrote: > > On Wed, 1 Jul 2020 15:51:25 +0100 Edward Cree wrote: > >> Unprivileged functions (such as VFs) may set their MTU by use of the > >> 'control' field of MC_CMD_SET_MAC_EXT, as used in efx_mcdi_set_mtu(). > >> If calling efx_ef10_mac_reconfigure() from efx_change_mtu(), the NIC > >> supports the above (SET_MAC_ENHANCED capability), and regular > >> efx_mcdi_set_mac() fails EPERM, then fall back to efx_mcdi_set_mtu(). > > Is there no way of checking the permission the function has before > > issuing the firmware call? > We could condition on the LINKCTRL flag from the MC_CMD_DRV_ATTACH > response we get at start of day; but usually in this driver we've > tried to follow the EAFP principle rather than embedding knowledge > of the firmware's permissions model into the driver.
I see. I'm actually asking because of efx_ef10_set_udp_tnl_ports(). I'd like to rewrite the UDP tunnel code so that NETIF_F_RX_UDP_TUNNEL_PORT only appears on the interface if it _really_ can do the offload. ef10 is the only driver I've seen where I can't be sure what FW will say.. (other than liquidio, but that's more of a kernel<->FW proxy than a driver, sigh). Is there anything I can condition on there? > I suppose it might make sense to go straight to efx_mcdi_set_mtu() > in the mtu_only && SET_MAC_ENHANCED case, use efx_mcdi_set_mac() > otherwise, and thus never have a fallback from one to the other. > WDYT? For the change of MTU that indeed seems much cleaner.
