ehca: IBM eHCA InfiniBand Device Driver
cover ehca: IBM eHCA InfiniBand Device Driver
Hello,
many thanks for your comments. They are very helpful for us. All 17 patches have to be applied, otherwise the driver won't compile.
We added an initial version to support large pages. At the moment we verified it only for 4K pages, because we're struggling to get a Linux kernel with 64K pages running properly on our system.
We would appreciate for any comments and feedbacks.
Changelog:
Differences to PatchSet http://openib.org/pipermail/openib-general/2006-March/018144.html
Differences to PatchSet http://openib.org/pipermail/openib-general/2006-March/017412.html
- Renamed module param tracelevel to debug_level
- Reformated MODULE_PARAM_DESC in ehca_main.c
- Removed EHCA_CACHE_CREATE / EHCA_CACHE_DESTROY macros
- Renamed debug_level sysfs entry to debug_mask
- debug_mask sysfs entry has now only one value
- Added LARGEPAGE support (EXPERIMENTAL)
- Changed locking for internal IDRs (for CQs and QPs)
- ehca_poll_eqs uses now mod_timer instead of add_timer
- Removed compile warnings in libehca because of missing header files
- Added function ibv_read_sysfs_file to be compatible with libibverbs 1.0
- Removed libsysfs usage in libehca
- Rename HCALLs defines from StudlyCaps to SHUTTING_CAPS
- Improve scaling code for completion queue
- Remove use of struct ib_gid in firmware bridge
- Improve coding style in firmware bridge
- Rework static rate encoding
- Removed ehca_kv_to_g()
- Splitted remaining shared kernel/userspace files
- Removed defines in user space to reuse kernel files
- Removed struct ehca_qp_core, ehca_cq_core
- Removed all trailing blanks found
- Fixed sparse warnings
- Improved eq SMP scaling
- Added fork access protection to queue entries
Kconfig | 6 Makefile | 29 ehca_av.c | 309 ++++++ ehca_classes.h | 314 ++++++ ehca_classes_pSeries.h | 253 ++++ ehca_cq.c | 445 ++++++++ ehca_eq.c | 225 ++++ ehca_hca.c | 286 +++++ ehca_irq.c | 712 ++++++++++++++ ehca_irq.h | 79 + ehca_iverbs.h | 183 +++ ehca_kernel.h | 162 +++ ehca_main.c | 973 +++++++++++++++++++ ehca_mcast.c | 198 +++ ehca_mrmw.c | 2492 +++++++++++++++++++++++++++++++++++++++++++++++++ ehca_mrmw.h | 145 ++ ehca_pd.c | 122 ++ ehca_qes.h | 278 +++++ ehca_qp.c | 1592 +++++++++++++++++++++++++++++++ ehca_reqs.c | 685 +++++++++++++ ehca_sqp.c | 126 ++ ehca_tools.h | 387 +++++++ ehca_uverbs.c | 409 ++++++++ hcp_if.c | 2028 +++++++++++++++++++++++++++++++++++++++ hcp_if.h | 398 +++++++ hcp_phyp.c | 97 + hcp_phyp.h | 97 + hipz_fns.h | 73 + hipz_fns_core.h | 126 ++ hipz_hw.h | 398 +++++++ ipz_pt_fn.c | 184 +++ ipz_pt_fn.h | 258 +++++ 32 files changed, 14069 insertions(+)
Quoted 3 lines · Heiko J Schick
many thanks for your comments. They are very helpful for us. All 17 patches have to be applied, otherwise the driver won't compile.
Don't expect much cheer and rejoicing over this. I suspect that akpm or Linus will either want the 17 patches merged into one or have a patchset where every single patch leaves the kernel in a working state, including working eHCA driver.
Generally, there seemed to be a bit more SHOUTING when compared to other kernel code. Might be something to look at as well.
Jörn
Signature · 4 lines
Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson
Quoted 4 lines · Jörn Engel
Don't expect much cheer and rejoicing over this. I suspect that akpm or Linus will either want the 17 patches merged into one or have a patchset where every single patch leaves the kernel in a working state, including working eHCA driver.
I don't like the idea to put the whole driver in one patch file. I would propose to put the patch "ehca: integration in Linux kernel" last instead of first, as Arnd mentioned. With that change we leave the kernel in a
working state when applying the patches.
Regards,
Heiko
Heiko> I don't like the idea to put the whole driver in one patch Heiko> file. I would propose to put the patch "ehca: integration Heiko> in Linux kernel" last instead of first, as Arnd Heiko> mentioned. With that change we leave the kernel in a Heiko> working state when applying the patches.
Yes, that makes sense.
And I can fold the patches into a single git changeset when we finally merge it, since I don't see any advantage to having the driver split into pieces. (No one is going to git biset a half-applied driver or anything like that)
- R.
Quoted 4 lines · On Thu, 27 Apr 2006 14:57:26 +0200 J=F6rn Engel <[email protected]>…
Don't expect much cheer and rejoicing over this. I suspect that akpm or Linus will either want the 17 patches merged into one or have a patchset where every single patch leaves the kernel in a working state, including working eHCA driver.
It doesn't matter in this case. The "don't break the build at any stage of a series" preference exists because it's extremely irritating to hit a won't-build in the middle of a git-bisect operation.
But anybody who is bisection searching for a bug won't want to enable a brand-new driver in their config, so no problems.