Roland Dreier <rdreier@xxxxxxxxx> wrote: > > I think there are two ways to proceed: > > - Start trying to figure out the best way to support the iSCSI offload > hardware that's out there. I don't know the perfect answer but I'm > sure we can figure something out if we make an honest effort. > > - Ignore the issue and let users of iSCSI offload hardware (and iWARP > and NFS/RDMA etc) stick to hacky out-of-tree solutions. This pays > off if stuff like the Intel CRC32C instruction plus faster CPUs (or > "multithreaded" NICs that use multicore better) makes offload > irrelevant. However this ignores the fundamental 3X memory bandwidth > cost of not doing direct placement in the NIC, and risks us being in > a "well Solaris has support" situation down the road. We've been here many times before. This is just the smae old TOE debate all over again. The fact with TOE is that history has shown that Dave's decision has been spot on. So you're going to have to come up with some really convincing evidence that shows we are all wrong and these TOE-like hardware offload solutions is the only way to go. You can start by collecting solid benchmark numbers that we can all reproduce and look into. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
