[openib-general] iWARP Branch Proposal
Tom Tucker
tom at ammasso.com
Mon Aug 8 07:14:08 PDT 2005
Roland:
Awesome list! Thanks for the quick and thorough review.
I'll add it to a TODO file in the branch and we'll keep track of our
progress against these items.
Answers to the questions follow...
TomT
> -----Original Message-----
> From: Roland Dreier [mailto:rolandd at cisco.com]
> Sent: Monday, August 08, 2005 8:52 AM
> To: Tom Tucker
> Cc: openib-general at openib.org
> Subject: Re: [openib-general] iWARP Branch Proposal
>
> Tom, thanks for posting your device driver so quickly. I realize that
> this is work-in-progress, and with that in mind I skimmed through the
> code and came up with some suggestions for your to-do list:
>
> - Kconfig: replace 'mthca' with 'ams1100' in help text :)
>
> - Replace all // comments with /* */.
>
> - Why are members of cc_pci_regs_t and cc_adapter_pci_regs_t volatile?
> Volatile declarations are almost inevitably buggy. It's better to
> use ordered accessors (readl(), writel(), etc) or insert explicit
> memory barriers.
[Tom] will do.
>
> - Get rid of most typedefs -- for example
>
> typedef enum {
> ...
> } foo_t;
>
> should become
>
> enum foo {
> ...
> };
>
> - Can cc_byteorder.h be eliminated? Most of the wrappers are
> definitely superfluous. Can the WR byte order ever change? ie are
> the cpu_to_wrXX() functions actually a useful abstraction?
[Tom] no, but the code was written when this was still in flux...
>
> - Most of cc_common.h can be removed -- eg CC_SLEEP, CC_PRINT are
useless
>
> - In ccil_api.h, rather than "#ifdef CC_LITTLE_ENDIAN" just use
> __constant_cpu_to_b32 or whatever.
>
> Most of the "PACKED" attributes are unnecessary (since the
> structures are already aligned). They'll lead to horrible code with
> gcc on ia64 etc.
>
> - In general, all the #ifdef X86_64 in the code looks like portability
> bugs.
> The best solution is just to make the code 32/64 clean, but at least
> we need to replace the test with #ifdef CONFIG_COMPAT
>
> - ccilnet_dbg.c is an awful lot of code just for debugging.
>
> - Get rid of compatibility with Linux 2.4 -- everywhere there's a test
> of LINUX_VERSION_CODE, just take the 2.6 code.
>
> - cc_mq_common.c: BUMP is pretty inefficient, does a divide every time
>
> - cc_qp_common.c: cc_memcpy8 corrupts FPU state, is it really needed?
> it's never called. Why is it declared in cc_mq_common.c?
> memcpy4 similarly corrupts state. If it's fixed to save CR0 and do
> clts, is it really faster than a normal memcpy (considering it also
> disables IRQs)?
>
[Tom] This file was shared between the user and kernel portions of our
standalone code. It will get incorporated into the devccil_qp.c file.
> This is all utterly non-portably anyway -- there needs to be a
> standard fallback for PPC64, IA64 etc.
>
> - Why is cc_queue.h needed? What is <linux/list.h> missing?
[Tom] nada, but the code was originally intended to be OS agnostic.
>
> - cc_types.h: get rid of NULL, TRUE, FALSE defines, cc_bool_t, etc.
> PTR_TO_CTX, CC_PTR_TO_64, etc seem busted on 64-bit archs.
> forget the macros, just cast to/from (unsigned long).
>
> - devccil_adapter.c: adapter_list seems to be a latent bug -- why does
> the driver need to keep a global list of adapters?
>
> - devccil.c: What is 'Static' -- why not 'static'??
> Probably all this code gets replaced by existing uverbs anyway.
>
> - devccil_lock.h: Get rid of lock wrappers, they're just
> obfuscation. And it seems CCTHREADSAFE won't ever be defined??
> The driver should always be threadsafe.
>
> - devccil_mem.c: ccil_big_malloc is horrible -- need a way to use
> non-contig memory.
>
> - devccil_srq.c: CCERR_NOT_IMPLEMENTED stubs not needed -- the
> existing midlayer will return -ENOSYS for unimplemented functions
> (ie NULL pointers in ib_device method table).
>
> - devccil_var.h: Defining your own version of PAGE_SHIFT etc. is just
> obfuscation; <linux/kernel.h> probably has all rounding functions
> you need. Custom ASSERT() can probably just be replaced with
> standard BUG_ON().
More information about the general
mailing list