On 02/07/2020 00:16, Jakub Kicinski wrote: > 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). I suppose it's time for me to describe the gory details ofhow EF10 tunnel offloads work, then. When changing the list of UDP tunnel ports, the MC patches the header-recogniser firmware and reboots the datapath CPUs (packet parsing on EF10 is done on a pair of DPCPUs with specialised instruction set extensions, and it wasn't originally designed with tunnel offloads in mind). Unfortunately, to synchronise everything afterwards, the MC then has to reboot itself too. Needless to say, this is fairly disruptive, especially as it's global across _both_ ports of a two-port NIC (which is what that EIO check in efx_ef10_set_udp_tnl_ports() is about: when you bring up a tunnel device, both netdevs get the ndo callback, the first one offloads the port, causing a reboot, which interrupts the second port's MCDI. Once the MC comes back up, the second netdev tries again to offload the UDP port, and this time the MC only has to increase a refcount, since the first netdev already added that port, so it can return success without another reboot).
> Is there anything I can condition on there? I _believe_ this is determined by another drv_attach flag, MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_TRUSTED, but again I'm not 100% sure; it might be the PRIMARY flag instead. I've CCed Matthew Slattery from our firmware team who should be able to answer. It also depends on the VXLAN_NVGRE firmware capability, which efx_ef10_set_udp_tnl_ports() already checks. Note that firmware capabilities can also change on an MC reboot (see the code that handles nic_data->must_check_datapath_caps). -ed
