-----"Krishnamraju Eraparaju" <krishna2@xxxxxxxxxxx> wrote: ----- >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx> >From: "Krishnamraju Eraparaju" <krishna2@xxxxxxxxxxx> >Date: 04/28/2020 10:01PM >Cc: faisal.latif@xxxxxxxxx, shiraz.saleem@xxxxxxxxx, >mkalderon@xxxxxxxxxxx, aelior@xxxxxxxxxxx, dledford@xxxxxxxxxx, >jgg@xxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx, bharat@xxxxxxxxxxx, >nirranjan@xxxxxxxxxxx >Subject: [EXTERNAL] Re: [RFC PATCH] RDMA/siw: Experimental e2e >negotiation of GSO usage. > >On Wednesday, April 04/15/20, 2020 at 11:59:21 +0000, Bernard Metzler >wrote: >Hi Bernard, > >The attached patches enables the GSO negotiation code in SIW with >few modifications, and also allows hardware iwarp drivers to >advertise >their max length(in 16/32/64KB granularity) that they can accept. >The logic is almost similar to how TCP SYN MSS announcements works >while >3-way handshake. > >Please see if this approach works better for softiwarp <=> hardiwarp >case. > >Thanks, >Krishna. > Hi Krishna, Thanks for providing this. I have a few comments: It would be good if we can look at patches inlined in the email body, as usual. Before further discussing a complex solution as suggested here, I would like to hear comments from other iWarp HW vendors on their capabilities regarding GSO frame acceptance and potential preferences. The extension proposed here goes beyond what I initially sent as a proposed patch. From an siw point of view, it is straight forward to select using GSO or not, depending on the iWarp peer ability to process large frames. What is proposed here is a end-to-end negotiation of the actual frame size. A comment in the patch you sent suggests adding a module parameter. Module parameters are deprecated, and I removed any of those from siw when it went upstream. I don't think we can rely on that mechanism. siw has a compile time parameter (yes, that was a module parameter) which can set the maximum tx frame size (in multiples of MTU size). Any static setup of siw <-> Chelsio could make use of that as a work around. I wonder if it would be a better idea to look into an extension of the rdma netlink protocol, which would allow setting driver specific parameters per port, or even per QP. I assume there are more potential use cases for driver private extensions of the rdma netlink interface? Thanks a lot! Bernard.
