[ofiwg] mapping adapter memory

[Reese Faucette (rfaucett)]

I’m not sure what you are saying – are you giving more examples to underscore that “yes, this is common and therefore libfabric should provide a way to deal with this.” (I agree!  I was only listing a couple of examples for reference)

Or are you saying “Look, there are these other ways of addressing the issue, why use libfabric?”  I think libfabric *should* support these more efficient usage models.

-reese


From: christoph at graphe.net [mailto:christoph at graphe.net] On Behalf Of Christoph Lameter
Sent: Wednesday, September 24, 2014 4:33 PM
To: Reese Faucette (rfaucett)
Cc: ofiwg at lists.openfabrics.org
Subject: Re: [ofiwg] mapping adapter memory

The VFIO capabilties of Linux allow the mapping of an adapter VF into user space. Intel has an implementation of a library that uses VFIO to control adapters and there is also a Mellanox userspace driver that can use VFIO. There is already a standard for this.

For the generic abstraction of a NIC in user space see http://dpdk.org


On Wed, Sep 24, 2014 at 5:41 PM, Reese Faucette (rfaucett) <rfaucett at cisco.com<mailto:rfaucett at cisco.com>> wrote:
Many adapters allow mapping memory regions on the adapter into user-space for efficient PIO-based sending and receiving.  This is often a big performance win and seems worthwhile finding an efficient abstract for.  Has this been discussed at all?

The approach of “let the provider find the best way to use the hardware resources and hide that from the user” will not always work in this case, as the constraints on adapter-mapped memory may prevent it from being a general solution.  For example, it may be a limited resource, and so not every EP will have access to it, and those that do may have restrictions that other EPs do not have (e.g. fewer send credits available, smaller MTU).

Any thoughts on whether this is worth trying to come up with some abstraction for?  From Cisco’s point of view, it definitely is – it requires some level of EP differentiation such that it cannot be totally transparent to the app, but it can drop latency by 20%, a worthwhile goal for us.

As another example, the new Solarflare NICs are pushing this as a feature also:
https://support.solarflare.com/index.php?option=com_cognidox&file=SF-111142-TC-1_Introduction_to_SFC91xx_ASIC_Family.pdf&task=download&format=raw&Itemid=17

See section on “PIO and Templates” – it’s not just us ☺

-reese


_______________________________________________
ofiwg mailing list
ofiwg at lists.openfabrics.org<mailto:ofiwg at lists.openfabrics.org>
http://lists.openfabrics.org/mailman/listinfo/ofiwg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20140924/69a8b2dd/attachment.html>