> However I came up with a tricky approach that might work well. We > would use two-element scatter lists for the receives, and post a > 40-byte dummy buffer first and then a 4096 byte buffer for the actual > packet. Since the only thing we do with the first 40 bytes is throw > them away, we wouldn't even have to make the 40 bytes part of the skb; > in fact we could have one buffer that every receive uses and never > even touch the first entry of the scatter list after initialization. > It would even save the skb_pull(skb, IB_GRH_BYTES); we currently do > after receiving messages. > > What do you think?
I thought the same thing before for one buffer allocation, I had a little bit concern about whether IB_GRH could be used later. I have done scatter-gather list patch already. It's based on the PAGE_SIZE whether to use one buffer or two buffer, similar as IPoIB-CM S/G code. It's under testing. The only thing I haven't finished is making S/G code more generica and merge IPoIB-CM S/G and IPoIB-UD S/G buffer allocation togather. Since IBM eHCA does support 4K MTU and we would like our customer to use this feature in OFED-1.3 release. If I merge the IPoIB-CM S/G code and IPoIB-UD S/G code, it would take much longer for testing. I wonder whether it's OK to push IPoIB-UD S/G first then merge IPoIB-UD and IPoIB-CM later. thanks Shirley _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
