> > > This means vmxnet3 PMD also should be updated, right? > > > > Yes, that's right. > > > > >Should that update > > > be part of tx_prep patchset? Or separate patch? > > > > Another question I suppose is who will do the actual patch for vmxnet3. > > Yong, are you ok to do the patch for vmxnet3, or prefer us to do that? > > Please note, that in both cases will need your help in testing/reviewing it. > > Konstantin > > It will be great if you can put together a patch as part of the entire > patchset on tx_prep() for vmxnet3 and I will definitely help review > it.
Ok. > > Regarding testing, I can definitely help but I don't have a testing harness > to cover the entire matrix (different ESX version, different > vmxnet3 device version, VM-VM, VM-physical over different uplinks, etc.) so > it will be limited. Related to this, I have the impression > that Intel has some existing coverage for vmxnet3 as well as other NICs. Do > we know if that will cover this use case as well? I'll ask our validation team, but I don't know off-hand what coverage for vmxnet3 we have. Konstantin > > > > > > > >>> > > > >> > > > >>>>> This is for any TX offload for which the upper layer SW would have > > > >> > > > >>>>> to modify the contents of the packet. > > > >> > > > >>>>> Though as I can see for qede neither PKT_TX_IP_CKSUM or > > > >> > > > >>>> PKT_TX_TCP_CKSUM > > > >> > > > >>>>> exhibits any extra requirements for the user. > > > >> > > > >>>>> Is that correct? > > > >> > > > >> > > > >
