On Mon, Aug 05, 2013 at 01:06:36PM -0700, Roland Dreier wrote: > On Mon, Aug 5, 2013 at 12:02 PM, Jason Gunthorpe > <[email protected]> wrote: > >> Wouldn't the following be a better path forward: > >> > >> - Add a new API (ibv_get_max_datagram_size() or some such) that > >> returns the real value as an int, based on the true MTU > >> - Have old query verbs continue to return only old MTU values, but > >> deprecate that field with the idea of removing it in a few years > > > It isn't that easy, one API certainly doesn't cover it. The MTU is in > > two structs: > > > struct ibv_port_attr > > struct ibv_qp_attr > > > Which touch ibv_query_port, ibv_modify_qp and ibv_query_qp. All of > > which need to be changed, and you can't change the _qp functions just > > by adding a new call. > > Well, for full generality I agree we would have to handle the QP > stuff. But for now at least the only QPs that need (or allow) MTU to > be set are connected (RC, UC and XRC) QPs. The current motivation for > allowing extended MTU is for datagrams. So strictly speaking we only > need to deal with the query port verb.
Okay, but if you want to narrow things to just be Jeff's application like that, then do we even need this to be part of verbs? IP path MTU should be discovered by a netlink routing query to lookup the target IP(s), the device maximum should not really be used by apps.. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
