On Wed, Jul 17, 2013 at 10:57 AM, Doug Ledford <[email protected]> wrote: >>> - doing it this way preserves ABI, so existing binaries are safe
>> I still don't get this. Wouldn't an existing binary be pretty >> surprised to get a value wildly out of range of the enum? > Yes, but there's no way around that without simply lying about the MTU. > So, the argument was made in the thread that historically, applications > have had to be modified when moved to a new link layer (aka, iWARP meant > IB apps had to be slightly modified for connection reasons, RoCE again > required some slight app modifications, etc) so this was seen as a case > of "the app will work on fabrics it already knows about, and will only > get confused if moved to this new fabric, and in that case, the app > needs to be modified anyway, so that's acceptable breakage for keeping > the apps working the rest of the time". That was the argument anyway. So I've been thinking about this for a while and this doesn't seem like the right tradeoff to me. If we break source compatibility, then everyone needs to add some annoying #ifdef-ery (and configure tests etc), even if they don't care about this new fabric. And by *not* breaking binary compatibility, we leave the risk of old binaries misbehaving. 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 We can implement this however is most convenient. If we want to preserve the kernel-user ABI (though it's not clear how to do that) then we can have code in libibverbs that implements all the necessary compatibility that makes sure the MTU enum field is one of the old enums, etc. Adding a new function to libibverbs is easy and safe, and the only case where things go wrong (if we add compatibility code in libibverbs) is a new kernel with a new device, but old libibverbs. But as Sean pointed out, it's not clear how we expect to return integer MTUs via the existing kernel-user ABI anyway, and we should really at least figure that out before we risk breaking userspace for no good reason. - R. -- 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
