Or Gerlitz wrote: > Mike Christie wrote: >> I am not sure what you are asking. Did you look at the patches? > > I gave it quick look before asking, I looked now again and I think > to understand this better - lets see if I'm in the correct direction: > > The I/OAT related kernel code serves the TCP stack for coping data > from the skb to the consumer buffer - for user space consumers this > is fairly simple and done behind the kernel cover. For kernel consumers > such as iscsi - things go a bit complex as there's richer API and some > flavors of it may not be applicable to use the dma functionality - or the > other way around - the dma functionality has to be exported/used by the > network stack consumer - namely iscsi, nfs, gfs, etc. So this patch set
Something like that. However, I do not know about other code. It seems like some nfs code uses kernel_recvmsg so it would be fine. Maybe the rpc code uses recvmsg and could be fine but some data transfer code uses a tcp_read_sock and skb_copy_bits and so it would need changes like iscsi. I think gfs2 sends data over block/scsi devices so this is only applicable if it was using tcp sockets and a API that was not converted already for locking data or metadata. Something like nbd looks fine as is. > does changes both in the network internals/api and in iscsi logic. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
