> LSO says, 'take this WR, in HW perform a split and transform operation > and create multiple SEND WRs'. > > The end result is still SEND, LSO does not change anything about the > layers below the WR. A SEND on a UD, RC, or RAW QP is still exactly the > same as before LSO was involved. Okay - this isn't what I think about when I read LSO at all (i.e. large segment offload, not large send [WR] offload). We have chained WRs. What your describing sounds like some sort of optimized version of that. > Critically, the operation of LSO should be indistinguishable on the > wire from actually generating the final WRs directly by the > application in the SQ. This concept should apply to the receive side as well. And generically, I don't think we even need to restrict WR offload to being the same type of operation. E.g. WRITE_WITH_SEND type of operation. > Typically an IP focused LSO will work like this: > > 'SEND' WR for 32k. > Split it into 1500 byte chunks, and make a new SEND for each chunk > Replicate bytes 0->NN of header onto every new SEND > Edit bytes XX->YY assuming they are an IPv4 header (update lengths, > checksum, sequence, etc) > Edit bytes YY->ZZ assuming they are a TCP or UDP header > (length,checksum,etc) > > In all cases the LSO is simply a transformation of a single SEND into > multiple SEND according to certain rules. > > The rules *must* be specified in the API. I think this is what you are > thinking about when you say 'protocol', but this is not IB or iWarp, > it is 'LSO packet format protocol #1' or something. I was under the impression that this was actually working at a protocol level that was above the transport level of the QP -- i.e. TCP/UDP/IP segmentation offload. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
