On 2023/3/10 6:50, Ronak Doshi wrote: > > > > On 3/8/23, 4:34 PM, "Yunsheng Lin" <linyunsheng@xxxxxxxxxx <mailto:linyunsheng@xxxxxxxxxx>> wrote: >>> >>> - if (adapter->netdev->features & NETIF_F_LRO) >>> + /* Use GRO callback if UPT is enabled */ >>> + if ((adapter->netdev->features & NETIF_F_LRO) && !rq->shared->updateRxProd) >>> >>> >> If UPT devicve does not support LRO, why not just clear the NETIF_F_LRO from >> adapter->netdev->features? >> >> >> With above change, it seems that LRO is supported for user' POV, but the GRO >> is actually being done. >> >> >> Also, if NETIF_F_LRO is set, do we need to clear the NETIF_F_GRO bit, so that >> there is no confusion for user? > > We cannot clear LRO bit as the virtual nic can run in either emulation or UPT mode. > When the vnic switches the mode between UPT and emulation, the guest vm is not > notified. Hence, we use updateRxProd which is shared in datapath to check what mode > is being run. So it is a run time thing? What happens if some LRO'ed packet is put in the rx queue, and the the vnic switches the mode to UPT, is it ok for those LRO'ed packets to go through the software GSO processing? If yes, why not just call napi_gro_receive() for LRO case too? Looking closer, it seems vnic is implementing hw GRO from driver' view, as the driver is setting skb_shinfo(skb)->gso_* accordingly: https://elixir.bootlin.com/linux/latest/source/drivers/net/vmxnet3/vmxnet3_drv.c#L1665 In that case, you may call napi_gro_receive() for those GRO'ed skb too, see: https://lore.kernel.org/netdev/166479721495.20474.5436625882203781290.git-patchwork-notify@xxxxxxxxxx/T/ > > Also, we plan to add an event to notify the guest about this but that is for separate patch > and may take some time. > > Thanks, > Ronak >
