search for: tx_buffers

Hi Michael, Excuse me for disturbing you with this letter! I?m using linux 4.7.2 virtio driver + X86 64 + smart nic to validate PF and VF virtio performance. The VF?s performance is >1Mpps, but the PF?s performance is only 500Kpps even if using 8 virtio queues. So I reviewed virtio iommu patch in detail. I worry dma map/unmap cost many cycles. Do you have any suggestion? Thanks a

Hi Michael, Excuse me for disturbing you with this letter! I?m using linux 4.7.2 virtio driver + X86 64 + smart nic to validate PF and VF virtio performance. The VF?s performance is >1Mpps, but the PF?s performance is only 500Kpps even if using 8 virtio queues. So I reviewed virtio iommu patch in detail. I worry dma map/unmap cost many cycles. Do you have any suggestion? Thanks a

The attached patch to the qemu emulation of the pcnet hardware fixes several problems. It will now only read and write a transmit or receive descriptor once. It will correctly handle transmitting frames with more than two fragments. It will discard oversize frames instead of corrupting memory. I have tested all the changes I have made and even seen an improvement in receive performance from

...but now I''m stumped. While building I get the following message: cc1: warnings being treated as errors netfront.c:41:32: error: variably modified ‘tx_freelist’ at file scope netfront.c:44:34: error: variably modified ‘rx_buffers’ at file scope netfront.c:45:34: error: variably modified ‘tx_buffers’ at file scope make[3]: *** [/usr/src/xen-4.0.1/stubdom/mini-os-x86_32-ioemu/netfront.o] Error 1 make[3]: Leaving directory `/usr/src/xen-4.0.1/extras/mini-os'' make[2]: *** [ioemu-stubdom] Error 2 make[2]: Leaving directory `/usr/src/xen-4.0.1/stubdom'' make[1]: *** [install-stubdo...

...gnttab_grant_access(0,virt_to_mfn(page),0); @@ -436,8 +437,9 @@ void netfront_xmit(unsigned char* data,i down(&tx_sem); local_irq_save(flags); + id = get_id_from_freelist(tx_freelist); + local_irq_restore(flags); - id = get_id_from_freelist(tx_freelist); buf = &tx_buffers[id]; page = buf->page; @@ -461,7 +463,7 @@ void netfront_xmit(unsigned char* data,i if(notify) notify_remote_via_evtchn(info->evtchn); + local_irq_save(flags); network_tx_buf_gc(); - local_irq_restore(flags); } _______________________________________________ Xen...

Since the vTPM implementations are being incorproated into Xen and possibly upstream Linux, I would like to see if this protocol change could be added before we have significant legacy implementations. If not, I still think it would be useful as either a v2 or negotiated protocol change. The current vTPM protocol is a copy of the network protocol. This was likely done for ease of implementation,

Hi, I hope I''m right here. If not then please point me in the right direction. My problem in short: I have problems using (pinning, mmu_update) physical pages from 0x900000 to 0xB1000 usualy. I''m writing my own little amd64 64bit toy kernel (based on Mini-OS as starting point) for xen and I run into problems with the way the start of day sets up the physical pages. My kernel