[libfabric-users] Queue size question
sean.hefty at intel.com
Wed Mar 24 11:51:54 PDT 2021
> This sort of situation is where I miss something like the (now deprecated) 'sockets'
> provider. As documented at least, it supported the entire interface. Of course that
> would be work to maintain (and I'm not volunteering, heh), but a thing doesn't have to
> perform well to be beneficial.
> It's an unfortunate irony that you have a consistent API that abstract away the
> differences between providers, but you have to fill your code with #ifdef's to work
> around the different features that are supported by those providers.
I completely understand. Ultimately, it's a trade-off that application developers must make between using the lowest common denominator of features, versus taking advantage of advanced network capabilities. For providers, it's also a trade-off to decide which features to implement for the markets that they want to target.
Libfabric is trying to provide a common framework for bridging that gap and not force an implementation on either side of the API.
And while it might seem like providers should just support all features, emulating them if they need to, it's not that simple. On some hardware, supporting a feature at all can significantly impact performance paths. Target side RMA counters are a good example of this. Even if it were reasonable to remove provider differences, apps would still deal with version differences.
More information about the Libfabric-users