Re: [ofa-general] Re: [ewg] to be discussed at the developer conference
Sean Hefty wrote: 7) the inform info code. Sean - you have implemented and attempted to push it through the sa caching push, but since the cache was rejected so did the inform info code. So the questions here - how do we make this push happen? are there any open issues, etc There either needs to be an in kernel user, or we need to reach agreement on the best way to expose this to userspace. Neither this, nor the multicast code are directly exported. IB multicast send-only (NonMemberSendOnly in IB spec notation) joins is the user that can enable the merge of the inform-info code. Specifically, the in-kernel user I suggest is the rdma-cm: enhance the librdmacm api to let the consumer specify that they want a send-only join, for such joins have the rdma-cm register to GID IN event on this group MGID and once such event happens, do the actual join on the group. How does this sounds? I have seen e-mails on the list that event subscription is used by userspace apps, but it is done via the MAD layer directly. Other than having each such app inventing the wheel in their inform-info low level coding, this is bad, since there is no reference counting and one process doing unregister makes the second process never get events (or they also implemented a reference counting daemon...), anyway, I think we want your implementation in, and the question is how we do that. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] to be discussed at the developer conference
Dror Goldenberg wrote: 2) as for IPoIB stateless offload - with Eli and Liran not planned to be there. Dror - do you intend to actually present the actual ipoib / core / drivers related design and implementation? Also, personally, I felt that the 1-2 slides you delivered on Sonoma where way below what would let one understand in what features exactly the HW supports, and I don't want to be referred to under-NDA docs, lets just have you provide a clear description regarding large-send and checksum offloading. Same for the HW interrupt mitigation, can be nice if you explain the problem, the solution and spare few words how does this goes with NAPI. One more thing is the LRO staff - its a pure SW optimization, if you think this should be in the ipoib code, some justification materials can be helpful. Yes, I will try to do a better job this time :) Lets do it more concrete: please comment if you will be presenting the actual SW design and more important, how much time you think you need, 20m is way below anything that allows for questions and some discussion - will 45m be enough? Will you referring the last patch set posted by Eli - (it has some pending comments that were not addressed) or Eli is going to post new version before the conference? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] to be discussed at the developer conference
Or Gerlitz wrote: Dror Goldenberg wrote: 2) as for IPoIB stateless offload - with Eli and Liran not planned to be there. Dror - do you intend to actually present the actual ipoib / core / drivers related design and implementation? Also, personally, I felt that the 1-2 slides you delivered on Sonoma where way below what would let one understand in what features exactly the HW supports, and I don't want to be referred to under-NDA docs, lets just have you provide a clear description regarding large-send and checksum offloading. Same for the HW interrupt mitigation, can be nice if you explain the problem, the solution and spare few words how does this goes with NAPI. One more thing is the LRO staff - its a pure SW optimization, if you think this should be in the ipoib code, some justification materials can be helpful. Yes, I will try to do a better job this time :) Lets do it more concrete: please comment if you will be presenting the actual SW design and more important, how much time you think you need, 20m is way below anything that allows for questions and some discussion - will 45m be enough? Will you referring the last patch set posted by Eli - (it has some pending comments that were not addressed) or Eli is going to post new version before the conference? Or. I haven't yet prepared the presentation. I am willing to cover whatever you think is important. Indeed 20m allotted time is too short. So, I should either adjust myself to this short time-slot or ask for more. Given that the other sessions are also 20m, I was thinking to have a short talk (with less of contents). If you feel that people can benefit from longer presentation, I will be happy to get more time for it. 40-45m will be great. -Dror ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED October 29 meeting summary on OFED 1.3 beta readiness
Hi Tziporet, On 10/30/07, Tziporet Koren [EMAIL PROTECTED] wrote: OFED October 29 meeting summary on OFED 1.3 beta readiness: 1. Beta release schedule: * The release is planed for next Monday Nov-5 * For this the rebase for 2.6.24-rc1 must be completed tomorrow * I will send status update on Thursday 2. Beta tasks status: 1. Fix compilation problems on PPC with 32 bits - Vlad Oren (Mellanox) - on work 2. Rebase kernel code on 2.6.24 rc1 (depending it's availability) - on work (please read mail from Vlad with instructions) 3. SPEC files should be part of each user space package - each owner should take the spec file 4. Multiple uDAPL libs (1.0 2.0) - Vlad and Arlin (Intel) 5. Fix all compilation and install issues - All What about release notes ? -- Hal Done tasks: o Add qperf test from Qlogic - Johann (Qlogic) o Support RHEL 5 up1 - Woody Vlad o Apply patches that fix warning of backport patches - Vlad (Mellanox) (one patch was not applied since we got no answer regarding it) o New MVAPICH package - Pasha DK (OSU) o Complete RDS work - Vlad (Mellanox) o Integrate all SDP features - Jim (Mellanox) o nes - updated backport patches - Glenn (NetEffect) 3. Bugs that should be with high priority for the beta are all compilation and install issues. I will publish the specific list of bugs Note: the bug severity in bugzilla are aimed to the GA release ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] to be discussed at the developer conference
Sean - SA-caching - 45m I think 30 minutes for this should be sufficient. - Sean ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED October 29 meeting summary on OFED 1.3 beta readiness
Hal Rosenstock wrote: Hi Tziporet, On 10/30/07, Tziporet Koren [EMAIL PROTECTED] wrote: OFED October 29 meeting summary on OFED 1.3 beta readiness: 1. Beta release schedule: * The release is planed for next Monday Nov-5 * For this the rebase for 2.6.24-rc1 must be completed tomorrow * I will send status update on Thursday 2. Beta tasks status: 1. Fix compilation problems on PPC with 32 bits - Vlad Oren (Mellanox) - on work 2. Rebase kernel code on 2.6.24 rc1 (depending it's availability) - on work (please read mail from Vlad with instructions) 3. SPEC files should be part of each user space package - each owner should take the spec file 4. Multiple uDAPL libs (1.0 2.0) - Vlad and Arlin (Intel) 5. Fix all compilation and install issues - All What about release notes ? -- Hal RN are not a must for the beta release (I updated the general notes) Anyone that have RN to update can send them to me against branch ofed_1_3 Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: to be discussed at the developer conference
At the highest level I think this developer summit is suffering from a lack of a clear goal. (The same could be said about the OpenFabrics alliance as a whole, but let's not get into that...) I'm supposed to give a talk about the basics of kernel development and I'm happy to do so, but that implies a certain target audience that is pretty disjoint from the developers who are leading development. In general the most valuable use of face-to-face time with code developers is to settle issues where email discussion has gotten stuck. If most people are not already familiar with the issue then it is very difficult to be productive. So with that said: 1) the long time and endless threads related to the SA caching thing need to be there. Sean - I saw that you prepare a session, correct? will you presenting few possible designs? This is the perfect type of thing to try and settle. 2) as for IPoIB stateless offload - with Eli and Liran not planned to be there. Dror - do you intend to actually present the actual ipoib / core / drivers related design and implementation? Given that there really hasn't even been an attempt to discuss this on the mailing list, I'm not convinced it's worth trying to rush through explaining it. I didn't think the patches were particularly hard to understand. 4) IPoIB connected mode UC support - Roland, can work on this start once the no-SRQ design/code is agreed and committed to a branch at your git? Is there a spec for attaching UC QPs to SRQs? Other than that I think it's just a matter of someone caring enough to start working on it. 5) IB 4K MTU - in IPoIB and elsewhere in the IB stack, same here, Roland, do you think a short session is needed No -- I don't know of any issues that need face-to-face discussion. 6) the netdev network batching RFCs - Krishna, Shirley, will someone from IBM can prepare a session to educate us on the matter and the status? Why do we need to spend face-to-face time on this? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: [ofa-general] Re: to be discussed at the developer conference
iWARP branch need time for connection management issues and a few others. There is impact on interoperability. Thanks, Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance Inc. phone: 781-768-5395 1601 Trapelo Rd. - Suite 16.Fax: 781-895-1195 Waltham, MA 02451 central phone: 781-768-5300 -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 30, 2007 4:38 PM To: Or Gerlitz Cc: EWG; OpenFabrics General; Dror Goldenberg Subject: [ofa-general] Re: to be discussed at the developer conference At the highest level I think this developer summit is suffering from a lack of a clear goal. (The same could be said about the OpenFabrics alliance as a whole, but let's not get into that...) I'm supposed to give a talk about the basics of kernel development and I'm happy to do so, but that implies a certain target audience that is pretty disjoint from the developers who are leading development. In general the most valuable use of face-to-face time with code developers is to settle issues where email discussion has gotten stuck. If most people are not already familiar with the issue then it is very difficult to be productive. So with that said: 1) the long time and endless threads related to the SA caching thing need to be there. Sean - I saw that you prepare a session, correct? will you presenting few possible designs? This is the perfect type of thing to try and settle. 2) as for IPoIB stateless offload - with Eli and Liran not planned to be there. Dror - do you intend to actually present the actual ipoib / core / drivers related design and implementation? Given that there really hasn't even been an attempt to discuss this on the mailing list, I'm not convinced it's worth trying to rush through explaining it. I didn't think the patches were particularly hard to understand. 4) IPoIB connected mode UC support - Roland, can work on this start once the no-SRQ design/code is agreed and committed to a branch at your git? Is there a spec for attaching UC QPs to SRQs? Other than that I think it's just a matter of someone caring enough to start working on it. 5) IB 4K MTU - in IPoIB and elsewhere in the IB stack, same here, Roland, do you think a short session is needed No -- I don't know of any issues that need face-to-face discussion. 6) the netdev network batching RFCs - Krishna, Shirley, will someone from IBM can prepare a session to educate us on the matter and the status? Why do we need to spend face-to-face time on this? - R. ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: to be discussed at the developer conference
On 10/30/07, Roland Dreier [EMAIL PROTECTED] wrote: So with that said: 1) the long time and endless threads related to the SA caching thing need to be there. Sean - I saw that you prepare a session, correct? will you presenting few possible designs? This is the perfect type of thing to try and settle. I agree. Sean - I don't see how a two years old open issue can be settled down in 30m, I would say we need between 45m and upto two hours for that. 2) as for IPoIB stateless offload - with Eli and Liran not planned to be there. Dror - do you intend to actually present the actual ipoib / core / drivers related design and implementation? Given that there really hasn't even been an attempt to discuss this on the mailing list, I'm not convinced it's worth trying to rush through explaining it. I didn't think the patches were particularly hard to understand. I think it would be good to have Dror explaining exactly what the HW knows to do (the Sonoma slides were very short in details). Things I think we want to discuss are: (A) why to put a SW only optimization (LRO) in Infiniband/networking driver (IPoIB) (B) the IB ICRC based checksum offload patch which you called silent data corruption enhancement etc Dror - I don't see how 30m would be enough, I would say 45m and upto an hour 4) IPoIB connected mode UC support - Roland, can work on this start once the no-SRQ design/code is agreed and committed to a branch at your git? Is there a spec for attaching UC QPs to SRQs? Other than that I think it's just a matter of someone caring enough to start working on it. Here's the thing: with the SRQ/UC spec and implementation status being unclear, once the no-SRQ code is in some repository, we can start code a no-SRQ/UC implementation. As for open issues, pls see http://lists.openfabrics.org/pipermail/general/2007-July/thread.html#37644where in the second message on the thread MST states The largest bit of work would be to add connection liveness detection code to active side. and then a whole discussion starts. If you tend to or just agree with Michael, can be helpful if we discuss how to do that. 5) IB 4K MTU - in IPoIB and elsewhere in the IB stack, same here, Roland, do you think a short session is needed No -- I don't know of any issues that need face-to-face discussion. OK 6) the netdev network batching RFCs - Krishna, Shirley, will someone from IBM can prepare a session to educate us on the matter and the status? Why do we need to spend face-to-face time on this? I thought that face-to-face meeting can include education, specifically when it is on interesting materials like this, which are about to effect the ipoib driver. Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED October 29 meeting summary on OFED 1.3 beta readiness
Tziporet, Vlad - I know the request went out on Monday to have all kernel backport patches etc updated to work with 2.6.24 by Wednesday. Unfortunately, due to other schedule commitments, we're not going to be able to turn those around in two days. My best estimate at the moment is that we will be able to submit the updated InfiniPath related backport patches by Friday. Regards, Betsy -- Betsy Zeller Director of Software Engineering HSG InfiniBand Engineering QLogic Corporation 2071 Stierlin Court, Suite 200 Mountain View, CA, 94043 1-650-934-8088 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED October 29 meeting summary on OFED 1.3 beta readiness
On Tue, 2007-10-30 at 16:40 +0200, Tziporet Koren wrote:
o Apply patches that fix warning of backport patches - Vlad
(Mellanox) (one patch was not applied since we got no answer
regarding it)
Yikes, I did drop that on the floor, didn't I? I'm sorry about that.
Here's a reply:
On Thu, 2007-10-25 at 10:05 +0200, Jack Morgenstein wrote:
Jeremy,
Why did you remove the likely and unlikely macros?
Isn't the compiler warning just on the missing != NULL ?
- Jack
It looks like we had something of an internal collision between two
patches. The one we submitted fixes a problem at the likely() unlikely()
macros confuse gcc into thinking that tail could be used before it is
assigned. (The engineer doesn't think gcc is producing better code due
to the use of likely/unlikely here.)
Another change that could be used to fix the issue would be along these
lines:
- struct sk_buff *tail;
[...]
- if (likely(skb_len (tail = skb_peek_tail(sk-sk_receive_queue)))
- unlikely(skb_tailroom(tail) = skb_len)) {
- skb_copy_bits(skb, 0, skb_put(tail, skb_len), skb_len);
- __kfree_skb(skb);
- skb = tail;
+ if (likely(skb_len)) {
+ struct sk_buff *tail = skb_peek_tail(sk-sk_receive_queue);
+ if (likely(tail) unlikely(skb_tailroom(tail) = skb_len)) {
+ skb_copy_bits(skb, 0, skb_put(tail, skb_len), skb_len);
+ __kfree_skb(skb);
+ skb = tail;
+ }
Which do you think looks better?
Sorry for the delay!
Jeremy
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH 1/14 v2] nes: module and device initialization
Thanks Roland. Let me know when you have your branch ready. OK, I pushed out a neteffect branch at git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git This has the driver from your git tree plus some compile fixes and cleanups (added as separate commits, so you can see what I did). If it suits you, let's work against that tree to continue cleaning things up -- you can send me patches or git pull requests to pick up new things. - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
