Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
On 4/19/08, Anthony Liguori [EMAIL PROTECTED] wrote: Blue Swirl wrote: On 4/17/08, Anthony Liguori [EMAIL PROTECTED] wrote: Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. The vector versions should also help SLIRP to add IP and Ethernet headers to the incoming packets. Yeah, I'm hoping that with my posted linux-aio interface, I can add vector support since linux-aio has a proper asynchronous vector function. Are we happy with the DMA API? If so, we should commit it now so we can start adding proper vector interfaces for net/block. Well, the IOVector part and bdrv_readv look OK, except for the heavy mallocing involved. I'm not so sure about the DMA side and how everything fits together for zero-copy IO. For example, do we still need explicit translation at some point? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
On 4/17/08, Anthony Liguori [EMAIL PROTECTED] wrote: Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. The vector versions should also help SLIRP to add IP and Ethernet headers to the incoming packets. I made an initial version of the vectored AIO SCSI with ESP. It does not work, but I can see that just using the vectors won't give too much extra performance, because at least initially the vector length is 1. Collecting the statuses may be tricky. block_aio_rw_v.diff Description: plain/text - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
Blue Swirl wrote: On 4/17/08, Anthony Liguori [EMAIL PROTECTED] wrote: Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. The vector versions should also help SLIRP to add IP and Ethernet headers to the incoming packets. Yeah, I'm hoping that with my posted linux-aio interface, I can add vector support since linux-aio has a proper asynchronous vector function. Are we happy with the DMA API? If so, we should commit it now so we can start adding proper vector interfaces for net/block. Regards, Anthony Liguori I made an initial version of the vectored AIO SCSI with ESP. It does not work, but I can see that just using the vectors won't give too much extra performance, because at least initially the vector length is 1. Collecting the statuses may be tricky. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
On 4/16/08, Anthony Liguori [EMAIL PROTECTED] wrote: Blue Swirl wrote: On 4/16/08, Anthony Liguori [EMAIL PROTECTED] wrote: This patch introduces a DMA API and plumbs support through the DMA layer. We use a mostly opaque structure, IOVector to represent a scatter/gather list of physical memory. Associated with each IOVector is a read/write function and an opaque pointer. This allows arbitrary transformation/mapping of the data while providing an easy mechanism to short-cut the zero-copy case in the block/net backends. This looks much better also for Sparc uses. I converted pcnet to use the IOVectors (see patch), it does not work yet but looks doable. Excellent! I fixed the bug, now pcnet works. Performance is improved by a few percent. The problem was that the vector was not freed. Maybe dynamic allocation is a bit fragile. In this case, the length of the vector is known, so it could be allocated once at init time. But would this work? The next step would be to add a vector version for packet receive. For ESP/SCSI, in addition to bdrv_readv/writev, AIO versions would need to be added. Last year I made a patch (attached) that made SLIRP use my version of IOVector, I could update it to this model. IMHO the read/write functions should be a property of the bus so that they are hidden from the device, for pcnet it does not matter as we have to do the swapping anyway. For an IOMMU that has a per-device mapping, the read/write functions have to operate on a per-device basis. No, I meant that there could be a bus layer that did the memory access and provided a specialized version of iovector_new without the handlers. But I think we can live with this, if things get too ugly we can add the layering later. pcnet_prepare.diff Description: plain/text pcnet_dma_api.diff Description: plain/text slirp_iov.diff Description: plain/text - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
Blue Swirl wrote: I fixed the bug, now pcnet works. Performance is improved by a few percent. The problem was that the vector was not freed. Maybe dynamic allocation is a bit fragile. In this case, the length of the vector is known, so it could be allocated once at init time. But would this work? For you, yes, but not for me. virtio scatter/gather lists can be very long. The API tries not to make assumptions about who's allocating what so you should be able to get away without a dynamic allocation if you were sufficiently motivated. The next step would be to add a vector version for packet receive. For ESP/SCSI, in addition to bdrv_readv/writev, AIO versions would need to be added. Last year I made a patch (attached) that made SLIRP use my version of IOVector, I could update it to this model. Yes, the vector version of packet receive is tough. I'll take a look at your patch. Basically, you need to associate a set of RX vectors with each VLANClientState and then when it comes time to deliver a packet to the VLAN, before calling fd_read, see if there is an RX vector available for the client. In the case of tap, I want to optimize further and do the initial readv() to one of the clients RX buffers and then copy that RX buffer to the rest of the clients if necessary. Regards, Anthony Liguori IMHO the read/write functions should be a property of the bus so that they are hidden from the device, for pcnet it does not matter as we have to do the swapping anyway. For an IOMMU that has a per-device mapping, the read/write functions have to operate on a per-device basis. No, I meant that there could be a bus layer that did the memory access and provided a specialized version of iovector_new without the handlers. But I think we can live with this, if things get too ugly we can add the layering later. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
On 4/16/08, Anthony Liguori [EMAIL PROTECTED] wrote: This patch introduces a DMA API and plumbs support through the DMA layer. We use a mostly opaque structure, IOVector to represent a scatter/gather list of physical memory. Associated with each IOVector is a read/write function and an opaque pointer. This allows arbitrary transformation/mapping of the data while providing an easy mechanism to short-cut the zero-copy case in the block/net backends. This looks much better also for Sparc uses. I converted pcnet to use the IOVectors (see patch), it does not work yet but looks doable. IMHO the read/write functions should be a property of the bus so that they are hidden from the device, for pcnet it does not matter as we have to do the swapping anyway. pcnet_dma_api.diff Description: plain/text - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/5] PCI DMA API (v3)
Blue Swirl wrote: On 4/16/08, Anthony Liguori [EMAIL PROTECTED] wrote: This patch introduces a DMA API and plumbs support through the DMA layer. We use a mostly opaque structure, IOVector to represent a scatter/gather list of physical memory. Associated with each IOVector is a read/write function and an opaque pointer. This allows arbitrary transformation/mapping of the data while providing an easy mechanism to short-cut the zero-copy case in the block/net backends. This looks much better also for Sparc uses. I converted pcnet to use the IOVectors (see patch), it does not work yet but looks doable. Excellent! IMHO the read/write functions should be a property of the bus so that they are hidden from the device, for pcnet it does not matter as we have to do the swapping anyway. For an IOMMU that has a per-device mapping, the read/write functions have to operate on a per-device basis. Regards, Anthony Liguori - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
