Since 2.6.35 is here, it's probably a good time to talk about 2.6.36
merge plans. All the pending things that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally. Please remind me.
As usual, when submitting a patch:
- Give a good changelog that explains what issue your patch
addresses, how you address the issue, how serious the issue is, and
any other information that would be useful to someone evaluating
your patch now, or trying to understand it years from now.
- Please make sure that you include a "Signed-off-by:" line, and put
any extra junk that should not go into the final kernel log *after*
the "---" line so that git tools strip it off automatically. Make
the subject line be appropriate for inclusion in the kernel log as
well once the leading "[PATCH ...]" stuff is stripped off. I waste a
lot of time fixing patches by hand that could otherwise be spent
doing something productive like watching youtube.
- Run your patch through checkpatch.pl so I don't have to nag you to
fix trivial issues (or spend time fixing them myself).
- Check your patch over at least enough so I don't see a memory leak
or deadlock as soon as I look at it.
- Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__")
and make sure it doesn't introduce new warnings. (A big bonus in
goodwill for sending patches that fix old warnings)
- Test your patch on a kernel with things like slab debugging and
lockdep turned on.
And while you're waiting for me to get to your patch, I sure wouldn't
mind if you read and commented on someone else's patch. We currently
have a big imbalance between people who are writing patches (many) and
people who are reviewing patches (mostly me). None of this means you
shouldn't remind me about pending patches, since I often lose track of
things and drop them accidentally.
I don't think it makes sense to break down what I merged by topics
this time around -- there wasn't anything big that I can think of. It
was really just a matter of small improvements, fixes, and cleanups
all over.
Here are a few topics I'm tracking that are not ready in time for the
2.6.36 window and will need to wait for 2.6.37 at least:
- XRC. While I think we made significant progress here, the fact is
that this is not ready to merge at the beginning of the merge
window, and so we'll need to keep working on it and wait for the
next merge window. I think this is just blocked on me at the
moment.
- IBoE. Same as XRC; we made significant progress (and I opened an
iboe branch to track this), and I think we have finally gotten the
user-kernel interface nailed down yet, but it's just too late.
- ummunotify-as-part-of-uverbs. I'm working on this but don't have
anything ready for the merge window.
- AF_IB work. I have not even had a chance to think about this yet,
since I haven't dug through earlier backlog items.
- mlx4 SR-IOV support. See AF_IB above.
Here all the patches I already have in my for-next branch:
Aleksey Senin (1):
IB: Rename RAW_ETY to RAW_ETHERTYPE
Alexander Schmidt (3):
IB/ehca: Fix bitmask handling for lock_hcalls
IB/ehca: Catch failing ioremap()
IB/ehca: Init irq tasklet before irq can happen
Arnd Bergmann (1):
IB/qib: Use generic_file_llseek
Bart Van Assche (3):
IB/srp: Use print_hex_dump()
IB/srp: Make receive buffer handling more robust
IB/srp: Export req_lim via sysfs
Ben Hutchings (1):
IB/ipath: Fix probe failure path
Chien Tung (1):
RDMA/nes: Store and print eeprom version
Dan Carpenter (2):
RDMA/cxgb4: Remove unneeded assignment
RDMA/cxgb3: Clean up signed check of unsigned variable
Dave Olson (1):
IB/qib: Allow PSM to select from multiple port assignment algorithms
David Rientjes (1):
RDMA/cxgb4: Remove dependency on __GFP_NOFAIL
Faisal Latif (1):
RDMA/nes: Fix hangs on ifdown
Ira Weiny (1):
IB/qib: Allow writes to the diag_counters to be able to clear them
Miroslaw Walukiewicz (1):
RDMA/nes: Read firmware version from correct place
Or Gerlitz (3):
IB/iser: Make needlessly global iser_alloc_rx_descriptors() static
RDMA/cxgb3: Make needlessly global iwch_l2t_send() static
RDMA/nes: Fix two sparse warnings
Peter Huewe (1):
RDMA/nes: Convert pci_table entries to PCI_VDEVICE
Ralph Campbell (5):
IB/qib: Avoid variable-length array
IB/qib: Turn off IB latency mode
IB/qib: Set cfgctxts to number of CPUs by default
IB/qib: Limit the number of packets processed per interrupt
IB/qib: Fix race between qib_error_qp() and receive packet processing
Roland Dreier (6):
IB/umad: Remove unused-but-set variable 'already_dead'
RDMA/nes: Rewrite expression to avoid undefined semantics
RDMA/cxgb4: Remove unneeded NULL check
RDMA/nes: Get rid of "set but not used" variables
RDMA/nes: Fix showing wqm_quanta
RDMA/nes: Fix misindented code
Sean Hefty (1):
IB/cm: Check LAP state before sending an MRA
Steve Wise (6):
RDMA/cxgb4: Add module option to tweak delayed ack
RDMA/cxgb4: Support variable sized work requests
RDMA/cxgb4: Fix race in fini path
RDMA/cxgb4: Use correct control txq
RDMA/cxgb4: Set/reset the EP timer inside EP lock
RDMA/cxgb4: Add timeouts when waiting for FW responses
--
Roland Dreier <[email protected]> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
On 8/5/2010 2:33 AM, Roland Dreier wrote:
Hi Roland,
>
> Here are a few topics I'm tracking that are not ready in time for the
> 2.6.36 window and will need to wait for 2.6.37 at least:
>
> - XRC. While I think we made significant progress here, the fact is
> that this is not ready to merge at the beginning of the merge
> window, and so we'll need to keep working on it and wait for the
> next merge window. I think this is just blocked on me at the
> moment.
Jack did all the changes you asked for and submitting the V3 patches on 2010/05/19,
which was long enough before the window.
What is the reason it will not be part of 2.6.36 kernel?
>
> - IBoE. Same as XRC; we made significant progress (and I opened an
> iboe branch to track this), and I think we have finally gotten the
> user-kernel interface nailed down yet, but it's just too late.
Eli sent the user space patch that was the last technical debate last week.
He will also send a new patch-set in day or two.
This feature was under a lot of technical review from the community.
Please consider including it in 2.6.36 after all.
In general - none of our new features going to be included and I wish to understand the reason behind it (I hope it's not personal :-)
regards
Tziporet
Hello Roland,
What about a series from Aleksey Senin
[PATCH V1 0/4] New RAW_PACKET QP type
[PATCH V1 1/4] Rename RAW_ETY to RAW_ETHERTYPE
[PATCH V1 2/4] New RAW_PACKET QP type definition
[PATCH V1 3/4] Security check on QP type
[PATCH V1 4/4] Add RAW_PACKET to ib_attach/detach mcast calls
And my patch RDMA/nes: IB_QPT_RAW_PACKET QP type support for nes driver
https://patchwork.kernel.org/patch/110252/
I see only one patch from that series in your plans
Aleksey Senin (1):
IB: Rename RAW_ETY to RAW_ETHERTYPE
Regards,
Mirek
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Roland Dreier
Sent: Thursday, August 05, 2010 1:34 AM
To: [email protected]; [email protected]
Subject: InfiniBand/RDMA merge plans for 2.6.36
Since 2.6.35 is here, it's probably a good time to talk about 2.6.36
merge plans. All the pending things that I'm aware of are listed below.
Boilerplate:
If something isn't already in my tree and it isn't listed below, I
probably missed it or dropped it unintentionally. Please remind me.
As usual, when submitting a patch:
- Give a good changelog that explains what issue your patch
addresses, how you address the issue, how serious the issue is, and
any other information that would be useful to someone evaluating
your patch now, or trying to understand it years from now.
- Please make sure that you include a "Signed-off-by:" line, and put
any extra junk that should not go into the final kernel log *after*
the "---" line so that git tools strip it off automatically. Make
the subject line be appropriate for inclusion in the kernel log as
well once the leading "[PATCH ...]" stuff is stripped off. I waste a
lot of time fixing patches by hand that could otherwise be spent
doing something productive like watching youtube.
- Run your patch through checkpatch.pl so I don't have to nag you to
fix trivial issues (or spend time fixing them myself).
- Check your patch over at least enough so I don't see a memory leak
or deadlock as soon as I look at it.
- Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__")
and make sure it doesn't introduce new warnings. (A big bonus in
goodwill for sending patches that fix old warnings)
- Test your patch on a kernel with things like slab debugging and
lockdep turned on.
And while you're waiting for me to get to your patch, I sure wouldn't
mind if you read and commented on someone else's patch. We currently
have a big imbalance between people who are writing patches (many) and
people who are reviewing patches (mostly me). None of this means you
shouldn't remind me about pending patches, since I often lose track of
things and drop them accidentally.
I don't think it makes sense to break down what I merged by topics
this time around -- there wasn't anything big that I can think of. It
was really just a matter of small improvements, fixes, and cleanups
all over.
Here are a few topics I'm tracking that are not ready in time for the
2.6.36 window and will need to wait for 2.6.37 at least:
- XRC. While I think we made significant progress here, the fact is
that this is not ready to merge at the beginning of the merge
window, and so we'll need to keep working on it and wait for the
next merge window. I think this is just blocked on me at the
moment.
- IBoE. Same as XRC; we made significant progress (and I opened an
iboe branch to track this), and I think we have finally gotten the
user-kernel interface nailed down yet, but it's just too late.
- ummunotify-as-part-of-uverbs. I'm working on this but don't have
anything ready for the merge window.
- AF_IB work. I have not even had a chance to think about this yet,
since I haven't dug through earlier backlog items.
- mlx4 SR-IOV support. See AF_IB above.
Here all the patches I already have in my for-next branch:
Aleksey Senin (1):
IB: Rename RAW_ETY to RAW_ETHERTYPE
Alexander Schmidt (3):
IB/ehca: Fix bitmask handling for lock_hcalls
IB/ehca: Catch failing ioremap()
IB/ehca: Init irq tasklet before irq can happen
Arnd Bergmann (1):
IB/qib: Use generic_file_llseek
Bart Van Assche (3):
IB/srp: Use print_hex_dump()
IB/srp: Make receive buffer handling more robust
IB/srp: Export req_lim via sysfs
Ben Hutchings (1):
IB/ipath: Fix probe failure path
Chien Tung (1):
RDMA/nes: Store and print eeprom version
Dan Carpenter (2):
RDMA/cxgb4: Remove unneeded assignment
RDMA/cxgb3: Clean up signed check of unsigned variable
Dave Olson (1):
IB/qib: Allow PSM to select from multiple port assignment algorithms
David Rientjes (1):
RDMA/cxgb4: Remove dependency on __GFP_NOFAIL
Faisal Latif (1):
RDMA/nes: Fix hangs on ifdown
Ira Weiny (1):
IB/qib: Allow writes to the diag_counters to be able to clear them
Miroslaw Walukiewicz (1):
RDMA/nes: Read firmware version from correct place
Or Gerlitz (3):
IB/iser: Make needlessly global iser_alloc_rx_descriptors() static
RDMA/cxgb3: Make needlessly global iwch_l2t_send() static
RDMA/nes: Fix two sparse warnings
Peter Huewe (1):
RDMA/nes: Convert pci_table entries to PCI_VDEVICE
Ralph Campbell (5):
IB/qib: Avoid variable-length array
IB/qib: Turn off IB latency mode
IB/qib: Set cfgctxts to number of CPUs by default
IB/qib: Limit the number of packets processed per interrupt
IB/qib: Fix race between qib_error_qp() and receive packet processing
Roland Dreier (6):
IB/umad: Remove unused-but-set variable 'already_dead'
RDMA/nes: Rewrite expression to avoid undefined semantics
RDMA/cxgb4: Remove unneeded NULL check
RDMA/nes: Get rid of "set but not used" variables
RDMA/nes: Fix showing wqm_quanta
RDMA/nes: Fix misindented code
Sean Hefty (1):
IB/cm: Check LAP state before sending an MRA
Steve Wise (6):
RDMA/cxgb4: Add module option to tweak delayed ack
RDMA/cxgb4: Support variable sized work requests
RDMA/cxgb4: Fix race in fini path
RDMA/cxgb4: Use correct control txq
RDMA/cxgb4: Set/reset the EP timer inside EP lock
RDMA/cxgb4: Add timeouts when waiting for FW responses
--
Roland Dreier <[email protected]> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Walukiewicz, Miroslaw wrote:
> Hello Roland, What about a series from Aleksey Senin [...] And my patch RDMA/nes: IB_QPT_RAW_PACKET QP type support for nes driver https://patchwork.kernel.org/patch/110252
Hi Mirek,
Reading your response @ http://marc.info/?l=linux-rdma&m=127954552519544
to the comments made during the review, I was under the impression that
you're going to try and modify the NES implementation, isn't this the
case any more?
Or.
Hello Or,
My patch was implemented using the most effective method available for current version of code and it is ready and working as a functionality.
For me another thing then functionality is an optimization of the existing SW paths in infiniband code and modification earlier written code to new interfaces.
Tomorrow I will start a new discussion regarding an optimization of the post_send/post_recv path. Thank you for reminder.
Regards,
Mirek
-----Original Message-----
From: Or Gerlitz [mailto:[email protected]]
Sent: Thursday, August 05, 2010 2:28 PM
To: Walukiewicz, Miroslaw
Cc: Roland Dreier; [email protected]; [email protected]
Subject: Re: InfiniBand/RDMA merge plans for 2.6.36
Walukiewicz, Miroslaw wrote:
> Hello Roland, What about a series from Aleksey Senin [...] And my patch RDMA/nes: IB_QPT_RAW_PACKET QP type support for nes driver https://patchwork.kernel.org/patch/110252
Hi Mirek,
Reading your response @ http://marc.info/?l=linux-rdma&m=127954552519544
to the comments made during the review, I was under the impression that
you're going to try and modify the NES implementation, isn't this the
case any more?
Or.
> In general - none of our new features going to be included and I wish
> to understand the reason behind it (I hope it's not personal :-)
It's not personal -- it was a combination of when things were ready and
when I had time to work on things, and unfortunately it all lined up so
I wasn't able to get anything big queued up this cycle.
--
Roland Dreier <[email protected]> || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html