Re: Performance enhancements: Checksum offloads.

["Durrant, Paul" <xadimgnik@xxxxxxxxx>]

On 07/06/2022 18:39, Edwin Torok wrote:
> > On 7 Jun 2022, at 11:24, Durrant, Paul <xadimgnik@xxxxxxxxx> wrote:
> >
> > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> > unless you have verified the sender and know the content is safe.
> >
> > On 07/06/2022 10:32, Martin Harvey wrote:
> > > Since I've been working on a performance related ticket today, a thought about 
> > > future enhancements:
> > > - Can we do checksum offloads all the way from H/W to the guest - if the dom0 
> > > drivers support the offloads, then there should be a way to get the calculated 
> > > checksums all the way thru to the guest?
> > Absolutely; the netif protocol has support for offloading (see 
> > NETRXF_data_validated) and you can set the 'Correct TCP/UDP Checksum Value' 
> > switch to 0 in the XENNET advanced properties if you want to avoid checksum 
> > recalculation.
> Thanks, we should probably do some internal benchmarks with that setting. At 
> least users with well-behaved applications could chose to avoid the perf hit.
Yes, benchmarking should generally be done with that setting turned off.
> Last time I looked at this there was some extra checksum recalculation going on when 
> splitting up large receive offloaded packets (which are IIRC around ~64k in size, much 
> larger than even jumbo frames) and those had to get a checksum from somewhere. If we can 
> tell it "its fine, it has a valid checksum" without actually computing one then 
> we can avoid all that, I assume the above setting will avoid recomputation in this case 
> too?
Yes indeed. There should be no need to re-calculate for LRO if the 
higher layers of the stack are sane.
> > The reason checksum recalculation is that validated packets coming from netback 
> > do not always have the correct checksum. Specifically packets from one VM to 
> > another VM on the same host may only contain a pseudo-header checksum. Also, I 
> > recall some NIC drivers zero-ing the checksum during validation. Now, you'd 
> > expect that when XENNET says to the network stack 'all is good with this 
> > packet' that nothing further up the stack should care about the checksum value 
> > however some of the good ole Citrix ICA stack (for example) actually does... so 
> > that's why we have to take the performance hit and fully recalculate. It's all 
> > rather silly.
> That would probably be broken when run on bare metal with NIC drivers that 
> support hardware offload too though?
Yes, and I wouldn't mind betting that ICA support folks advise customers 
to turn off checksum offload in some environments.
> Perhaps there could be a setting to zero the checksum field when its 
> computation is offloaded to more easily detect these cases, at least as 
> something to use during debugging / automated testing?
I think I did something like that in the past, before adding the 
recalculation code because we had support escalations where e.g. a dom0 
NIC driver update was suddenly causing all virtual desktop instances on 
the host to start to fail... but it only affected hosts with a 
particular vendor's NIC.
Cheers,

  Paul