[openib-general] Re: [PATCH 0 of 18] ipath driver - for inclusion in 2.6.17

Roland Dreier rdreier at cisco.com
Fri Mar 24 13:19:32 PST 2006


    Bryan> Would your preference be to slap #ifdefs around those, or
    Bryan> to just require CONFIG_NET in Kconfig?  The core driver
    Bryan> should work fine without any kernel-level networking
    Bryan> support, so I suppose the former makes more sense.

Having #ifdef CONFIG_NET all over is definitely suboptimal.
Unfortunately it looks kind of hard to untangle your skb use from the
rest of the driver, so putting a dependency on NET might be the best bet.

    Bryan> That's going to be interesting to test, because I don't
    Bryan> have any ia64 hardware to even compile on.  I have tested
    Bryan> on x86_64 and powerpc, so this seems like an arch-level
    Bryan> header deficiency.  Any idea what to do about it?

How are you building on powerpc?  I don't see any way to turn on
CONFIG_PCI_MSI except on i386/x86_64 and ia64.

Anyway building an ia64 cross toolchain is easy with http://kegel.com/crosstool

I would just get rid of your atomic_clear_mask() and atomic_set_mask()
calls.  They're bogus because you're not even operating on an
atomic_t, and not many architectures implement them.  Just take a lock
if you need to modify the bitmap atomically.  A spinlock is cheaper
than two atomic operations (although I guess for a slow path, it hurts
in .text size).

    Bryan> I've been building with C=1 for months.  I'll see if I can
    Bryan> figure out why you're getting such different results.

It's probably because I use CF=-D__CHECK_ENDIAN__ too.

There are a few other things I don't think we've really closed on:

 - The whole duplicated SMA / ipath_verbs doesn't work without ib_mad loaded.

 - Andrew raised some questions about the special "pick a device for
   me" that I'm not sure we satisfied him on.  I don't find the
   /dev/ptmx argument that convincing, since I don't think /dev/ptmx
   is considered the best example of interface design.

 - It looks like ipath_copy.c is completely unused now that you're not
   including the ipath_ether driver.

 - R.



More information about the general mailing list