[openib-general] OpenIB SWG Face to Face 9/9 Meeting

[Roland Dreier]

A few comments (since I was not around for the whole meeting):

    Hal> SM support is needed for initial deliverable for those
    Hal> without an embedded SM (e.g. back to back HCAs).  OpenSM
    Hal> obtains access to kernel via character device ioctls Is this
    Hal> acceptable ? There were differing views on this.  The kernel
    Hal> support for this is in core/useraccess_xxx.c as is done via
    Hal> read/write (to send and receive MADs). Needs to be made 32/64
    Hal> clean and saner prior to kernel submission.

I'm pretty sure sane ioctls will be acceptable.  If the semantics of
the character device are read() for receive, write() for send and
ioctl() to set parameters, I don't see much problem.  If there's
resistance to this we can look for alternatives (eg a new socket
family and socket options instead of ioctl?).  

Actually the userspace stuff pretty much needs a complete rewrite for
sysfs-ication etc.  However I don't think this is much work and I can
bang it out pretty quickly.

    Hal> mthca is missing RDMA support and will be added beyond phase
    Hal> 1. No Arbel options are supported (only Tavor compatibility
    Hal> mode).  Perhaps can bind CQs to different MSI-X lines ?

No firmware that supports Arbel native mode is available yet anyway.

I've been intending to implement multiple CQ event handlers for a
while but I wanted to defer design/discussion of the API until after
we had the basics working (and Mellanox has not released firmware with
MSI-X support either).

    Hal> Should we go into Andrew Morton's tree first ?

I don't think this a decision for us to make.  When we get closer to
having patches to submit, we can work with Linus and Andrew to figure
out the best way to get them merged.  My feeling is that since our
changes are pretty self-contained (the only core change I know of is
to add ARPHRD_INFINIBAND multicast support) there's not much risk in
merging upstream, so there's not much need to go through the -mm
tree.  However if Andrew does want to have our patches soak in -mm for
a while, that's not a problem either.

    Hal> What about OSDL ? Who can supply IB hardware for them ? Some
    Hal> number of HCAs and a switch would be needed. They also may
    Hal> have a budget for this.

OSDL does not accept donated agreement -- they insist on buying
everything they use.

    Hal> Need to make sure that the multicast mapping solution is
    Hal> acceptable to Linux kernel network maintainer if this impacts
    Hal> the core networking files.

I don't expect any problem here but it wouldn't hurt for someone to
actually write the patch and run it by Dave Miller and
netdev at oss.sgi.com in advance.

    Hal> Roland indicates he will shortly post flash support including
    Hal> building with autoconf. This requires no kernel support. It
    Hal> may need to be just GPL'd only as it use pcitools.

Just posted.  It is indeed GPLed because it links with pciutils.

 - R.