Hi, BTW, this is not the only NAPI issue here. When looking into cleanup of resources in this driver, a call to netif_napi_del() is missing (though there is a call to napi_disable(), which is not enough for proper cleanup). Best, Rami Rosen http://ramirose.wix.com/ramirosen On Tue, Aug 13, 2013 at 11:41 PM, Francois Romieu <romieu@xxxxxxxxxxxxx> wrote: > (no top-post nor lazy quote please) > > David Shwatrz <dshwatrz@xxxxxxxxx> : > [...] >> In the napi_gro_receive() we check that the device supports >> NETIF_F_GRO, but I don't see that we inspect checksum or that >> NETIF_F_GRO is depends on checksum. > > napi_gro_receive is irrelevant. Let aside tunnel, the real work happens > in the protocol specific gro_receive handlers. > > However I am an happy retard and I missed that tcp gro stopped depending > on Rx checksum since commit 861b650101eb0c627d171eb18de81dddb93d395e. :o/ > > So, yes, napi_gro_receive could be used. > > -- > Ueimor > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html