[openib-general] nightly osm_sim report 2007-01-18:normal completion
OSM Simulation Regression Summary OpenSM rev = Wed_Jan_17_13:32:47_2007 c2a39a ibutils rev = Wed_Jan_3_11:42:12_2007 913448 Total=410 Pass=410 Fail=0 Pass: 30 Stability IS1-16.topo 30 Pkey IS1-16.topo 30 OsmTest IS1-16.topo 30 OsmStress IS1-16.topo 30 Multicast IS1-16.topo 30 LidMgr IS1-16.topo 10 Stability IS3-loop.topo 10 Stability IS3-128.topo 10 Pkey IS3-128.topo 10 OsmTest IS3-loop.topo 10 OsmTest IS3-128.topo 10 OsmStress IS3-128.topo 10 Multicast IS3-loop.topo 10 Multicast IS3-128.topo 10 LidMgr IS3-128.topo 10 FatTree part-4-ary-3-tree.topo 10 FatTree merge-roots-reorder-4-ary-2-tree.topo 10 FatTree merge-roots-4-ary-2-tree.topo 10 FatTree merge-root-4-ary-3-tree.topo 10 FatTree merge-root-12-ary-2-tree.topo 10 FatTree merge-2-ary-4-tree.topo 10 FatTree half-4-ary-3-tree.topo 10 FatTree blend-4-ary-2-tree.topo 10 FatTree 4-ary-4-tree.topo 10 FatTree 4-ary-3-tree.topo 10 FatTree 32nodes-3lvl-is1.topo 10 FatTree 2-ary-4-tree.topo 10 FatTree 12-node-spaced.topo 10 FatTree 12-ary-2-tree.topo Failures: ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]
> What about pure opensource - http://sourceware.org/pthreads-win32/? It > is licensed under LGPL, I see on the net many positive reports about > stability and usability. I used it to do a windows port of linux complib at some point and opensm seemed to work fine with it. What it was lacking at that point was support for 64 bit applications, and for some reason (which is still unclear to me) there was a strong desire to run opensm in 64 bit mode. Seems to have been fixed now, BTW. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/core - ib_umad can cause address alignment fault on ia64
> Quoting Ralph Campbell <[EMAIL PROTECTED]>: > Subject: [PATCH] IB/core - ib_umad can cause address alignment fault on ia64 > > IB/core - ib_umad can cause address alignment fault > > In user_mad.c, the definition for struct ib_umad_packet includes > struct ib_user_mad at an odd 32-bit offset. When ib_umad_write() > tries to assign rmpp_mad->mad_hdr.tid, there is an alignment fault on > architectures which have strict alignment for load/stores. > This patch fixes the problem by changing the offset on which > struct ib_user_mad is defined within struct ib_umad_packet. > > Thanks go to John W. Marland <[EMAIL PROTECTED]> for finding this. > > Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]> > > diff -r b1128b48dc99 drivers/infiniband/core/user_mad.c > --- a/drivers/infiniband/core/user_mad.c Fri Jan 12 20:00:03 2007 + > +++ b/drivers/infiniband/core/user_mad.c Wed Jan 17 14:09:37 2007 -0800 > @@ -125,7 +125,7 @@ struct ib_umad_packet { > struct ib_mad_send_buf *msg; > struct ib_mad_recv_wc *recv_wc; > struct list_head list; > - intlength; > + long length; > struct ib_user_mad mad; > }; This does not make sense to me - do we have to replace all int fields with long now? Looks like a compiler or makefile bug in your setup - struct fields should be naturally aligned. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [libibcm] [PATCH] Added checks to memory allocation failure when using asprintf
Thanks - committed. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH TRIVIAL] opensm: make osm object local
On Wed, 2007-01-17 at 19:44, Sasha Khapyorsky wrote: > This defines osm object as local variable. > > Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]> Thanks. Applied. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH TRIVIAL] opensm: make osm object local
This defines osm object as local variable. Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]> --- osm/opensm/main.c | 12 +--- 1 files changed, 1 insertions(+), 11 deletions(-) diff --git a/osm/opensm/main.c b/osm/opensm/main.c index ff517eb..919f71d 100644 --- a/osm/opensm/main.c +++ b/osm/opensm/main.c @@ -57,17 +57,6 @@ #include #include -/ - D E F I N EG L O B A LV A R I A B L E S -*/ -/* - This is the global opensm object. - One opensm object is required per subnet. - Future versions could support multiple subnets by - instantiating more than one opensm object. -*/ -osm_opensm_t osm; - volatile unsigned int osm_exit_flag = 0; static volatile unsigned int osm_hup_flag = 0; @@ -545,6 +534,7 @@ main( int argc, char* argv[] ) { + osm_opensm_t osm; osm_subn_opt_topt; ib_net64_tsm_key = 0; ib_api_status_t status; -- 1.5.0.rc0.g2484-dirty ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]
On 18:24 Thu 11 Jan , Yevgeny Kliteynik wrote: > Hi Sasha, > > Sasha Khapyorsky wrote: > > Hi Yevgeny, > > > > On 09:47 Wed 10 Jan , Yevgeny Kliteynik wrote: > >> Hi Sasha, > >> > >> Sasha Khapyorsky wrote: > >>> Hi Yevgeny, > >>> > >>> On 12:05 Tue 09 Jan , Yevgeny Kliteynik wrote: > Hi Sasha. > Thanks for spotting this issue - I missed it when I reviewed the patch. > Here's how things look in windows: > * openlog() and closelog() are redefined to nothing in windows config > header > * cl_log_event() implementation on windows does all the work - gets > handler > to event log, logs the message, and closes the handler. > It does *not* uses syslog(). > > To use syslog/sysopen/sysclose on windows, a user have to install some > package (e.g. "Interix") that provides various daemons (such as > syslogd), > similar to Linux/Unix: > http://msdn2.microsoft.com/en-us/library/ms811897.aspx#ucmgch10_topic12 > http://www.interix.com/ > >>> And this is not done for WinOpenSM now. Is this would be useful option? I > >>> guess this could solve a lot of compatibility problems and simplify the > >>> porting dramatically, right? > >> I'll address this question to the windows guys. But I seriously doubt that > >> they would want to make OSM depend on some third-party product, whether it > >> is commercial or free. > > > > I doubt too :(. But ask them if it is not too hard. Interesting, how > > WinOSM development works? AFAIK it is open source and published on the > > net. Who is the maintainer? Is there any active mailing list? > > If the product is commercial, then the answer is no. If it is free, > then there might be some license issues that may cause problems. But > theoretically, if there would be some high-quality free product than > will not pose any legal problems distributing it, and if it will be > *really* useful (not just for logging functions), then it's possible. So what do you mean - "Interix" has (or may have) legal issues if it will be used with OpenSM? What about pure opensource - http://sourceware.org/pthreads-win32/? It is licensed under LGPL, I see on the net many positive reports about stability and usability. > As for the mailing list it's [EMAIL PROTECTED] You can access > it here: http://openib.org/mailman/listinfo/openib-windows > > So replacing cl_log_event() with syslog() would definitely cause a > problem. > > A (pretty ugly) solution can be writing a wrapper function to > cl_log_event() > on windows and redefining syslog() to use this wrapper. > >>> Like #define syslog() cl_log_event() ? Not so ugly (better than > >>> combination of openlog()/closelog() and "unrelated" cl_log_event()), > >>> and perfectly simple IMO. > >> "#define syslog() cl_log_event()" will not do the job, since these > >> functions > >> have different definitios: > >>syslog(int priority, char *message, ...); > >>cl_log_event(char*, cl_log_type_t, char*, void*, uint32_t); > >> so there should be wrapper just for windows that will prepare the message > >> for cl_log_event() as a single string. > > > > Understood. > > > > And what the purpose of: > > > > #ifdef WIN32 > > OsmReportState(buffer); > > #endif /* WIN32 */ > > > > in osm_log() (right after cl_log_event()/syslog())? > > It reports SM states when SM is running as window service. Could this be moved from common code into syslog() wrapper? Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Yevgeny, On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote: > Hi Hal > > The following series of six patches implements QoS policy file parser: > > 1. QoS parser Lex file > 2. QoS parser Lex-generated c file > 3. QoS parser grammar (Yacc) file > 4. QoS parser Yacc-generated grammar c and h file > 5. QoS parser header file that defines parse tree data structures > 6. Changes in makefiles and configure.in file for compiling QoS parser files Is there any description of proposed format and functionality? Also what about using human readable formats? Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
On 17:04 Wed 17 Jan , Jeff Squyres wrote: > On Jan 17, 2007, at 5:02 PM, Sasha Khapyorsky wrote: > > >>1. Putting the MPI release in git provides a level of OFED-specific > >>history and version control. This was explicitly stated on the call > >>yesterday. > > > >Which history information we are expecting to see between bin-file- > >ver1 > >and bin-file-ver2, where files bin-file-ver* are never changed? > > I think the point is when they *do* change. But when they do change we update the version and create new binary file - bin-file-ver2.1 . > >>2. MPI's have concrete "releases" to OFED just like all other ULP's, > >>especially if there is any OFED-specific packaging involved in the > >>MPI's release. This was not stated on the call, but it makes sense > >>to me. > >> > >>3. Putting everything in git makes it nicely uniform for OFED to be > >>assembled. This was not stated on the call, and I'm sure it's not a > >>requirement, but it is a little nice to be uniform when assembling > >>OFED (my $0.02). > >> > >>4. We used to put the MPI releases in SVN (tarball or SRPM) for prior > >>OFED release processes, > > > >Yes, and it was bad practice IMO. GIT and SVN are version tracking > >tools, > >mostly usable for sources and not for compilation results. Why one > >should install git if everything really needed is just to download > >file > >from the server? > > The SRPMs are not compilation results. Right, it is source packaging results - similar meaning. > Putting compilation results > in a version tracking tool would be useless, I agree. > > >>so putting them in a git seems to parallel > >>that procedure. > > > >Just file hosting should be perfectly enough for the all above. I > >don't > >see any real reason to use git as non-versioned binary files storage. > > I think the point was that you could then get a definitive set of > files that were shipped in OFED version x.y -- you could accurately > rebuild OFED regardless of what files are hosted on the other open > source web sites. This is tracked in fetch/build scripts, and it is under version control. External packages can be hosted (or just copyed) on the OFA site. > A perfect example is that the MVAPICH1 package in > OFED is prepared by Mellanox, not OSU. So there was no web site to > make that tarball and support files available from. Another example > is that open source projects may decide to no longer host older > versions of their software -- OFA may not be able to control that. > > The point here is that version control principles apply to binaries > just as well as they apply to sources (indeed, the files we're > talking about here are binary bundles of sources). Only if we are going to change such files, but I guess in our case we are not - instead we will create new package files with new versions. Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
On 00:22 Thu 18 Jan , Michael S. Tsirkin wrote: > > > I don't really care one way or another; this was just my > > > understanding of why it was requested. > > > > > > > > > > > > > Jeff is correct - I requested this from the reasons above. > > I think all we need for OFED is just a *fixed* URL where OFED > build script can download the OFED-specific SRPM for 1.2. > > If this is a problem for OSU it can be hosted at the openfabrics server. > > Correct? Seems reasonable for me. Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
This is such a trivial matter that it really isn't worth arguing about. :-) Tell us MPI guys how you want MPI releases published to OFED and we'll do it. On Jan 17, 2007, at 5:22 PM, Michael S. Tsirkin wrote: >>> I don't really care one way or another; this was just my >>> understanding of why it was requested. >>> >>> >>> >> >> Jeff is correct - I requested this from the reasons above. > > I think all we need for OFED is just a *fixed* URL where OFED > build script can download the OFED-specific SRPM for 1.2. > > If this is a problem for OSU it can be hosted at the openfabrics > server. > > Correct? > -- > MST -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
> > I don't really care one way or another; this was just my > > understanding of why it was requested. > > > > > > > > Jeff is correct - I requested this from the reasons above. I think all we need for OFED is just a *fixed* URL where OFED build script can download the OFED-specific SRPM for 1.2. If this is a problem for OSU it can be hosted at the openfabrics server. Correct? -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] IB/core - ib_umad can cause address alignment fault on ia64
IB/core - ib_umad can cause address alignment fault In user_mad.c, the definition for struct ib_umad_packet includes struct ib_user_mad at an odd 32-bit offset. When ib_umad_write() tries to assign rmpp_mad->mad_hdr.tid, there is an alignment fault on architectures which have strict alignment for load/stores. This patch fixes the problem by changing the offset on which struct ib_user_mad is defined within struct ib_umad_packet. Thanks go to John W. Marland <[EMAIL PROTECTED]> for finding this. Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]> diff -r b1128b48dc99 drivers/infiniband/core/user_mad.c --- a/drivers/infiniband/core/user_mad.cFri Jan 12 20:00:03 2007 + +++ b/drivers/infiniband/core/user_mad.cWed Jan 17 14:09:37 2007 -0800 @@ -125,7 +125,7 @@ struct ib_umad_packet { struct ib_mad_send_buf *msg; struct ib_mad_recv_wc *recv_wc; struct list_head list; - intlength; + long length; struct ib_user_mad mad; }; ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH/RFC 2.6.21] ehca: ehca_uverbs.c: refactor ehca_mmap() for better readability
Hello, here is a patch for ehca_uverbs.c with the following changes: - Rename mm_open/close() to ehca_mm_open/close() respectively - Refactor ehca_mmap() into sub-functions ehca_mmap_cq/qp(), which then call the new common sub-functions ehca_mmap_fw() and ehca_mmap_queue() to register firmware memory block and queue pages respectively Roland, please note that I applied the previous patches to your git tree for-2.6.21 before creating this patch. I also realized a compile issue with the patch from Michael T. in ehca_reqs.c regarding "return qp pointer in ib_wc". For this I'll send another patch. Thanks! Nam Signed-off-by Hoang-Nam Nguyen <[EMAIL PROTECTED]> --- ehca_uverbs.c | 266 +++--- 1 file changed, 146 insertions(+), 120 deletions(-) diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_uverbs.c infiniband_work/drivers/infiniband/hw/ehca/ehca_uverbs.c --- infiniband/drivers/infiniband/hw/ehca/ehca_uverbs.c 2007-01-17 21:39:01.0 +0100 +++ infiniband_work/drivers/infiniband/hw/ehca/ehca_uverbs.c2007-01-17 21:17:00.0 +0100 @@ -68,7 +68,7 @@ int ehca_dealloc_ucontext(struct ib_ucon return 0; } -static void mm_open(struct vm_area_struct *vma) +static void ehca_mm_open(struct vm_area_struct *vma) { u32 *count = (u32*)vma->vm_private_data; if (!count) { @@ -84,7 +84,7 @@ static void mm_open(struct vm_area_struc vma->vm_start, vma->vm_end, *count); } -static void mm_close(struct vm_area_struct *vma) +static void ehca_mm_close(struct vm_area_struct *vma) { u32 *count = (u32*)vma->vm_private_data; if (!count) { @@ -98,26 +98,150 @@ static void mm_close(struct vm_area_stru } static struct vm_operations_struct vm_ops = { - .open = mm_open, - .close = mm_close, + .open = ehca_mm_open, + .close = ehca_mm_close, }; -static int ehca_mmap_qpages(struct vm_area_struct *vma, struct ipz_queue *queue) +static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas, + u32 *mm_count) { + int ret; + u64 vsize, physical; + + vsize = vma->vm_end - vma->vm_start; + if (vsize != EHCA_PAGESIZE) { + ehca_gen_err("invalid vsize=%lx", vma->vm_end - vma->vm_start); + return -EINVAL; + } + + physical = galpas->user.fw_handle; + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); + ehca_gen_dbg("vsize=%lx physical=%lx", vsize, physical); + /* VM_IO | VM_RESERVED are set by remap_pfn_range() */ + ret = remap_pfn_range(vma, vma->vm_start, physical >> PAGE_SHIFT, + vsize, vma->vm_page_prot); + if (unlikely(ret)) { + ehca_gen_err("remap_pfn_range() failed ret=%x", ret); + return -ENOMEM; + } + + vma->vm_private_data = mm_count; + (*mm_count)++; + vma->vm_ops = &vm_ops; + + return 0; +} + +static int ehca_mmap_queue(struct vm_area_struct *vma, struct ipz_queue *queue, + u32 *mm_count) +{ + int ret; u64 start, ofs; struct page *page; - int rc = 0; + + vma->vm_flags |= VM_RESERVED; start = vma->vm_start; for (ofs = 0; ofs < queue->queue_length; ofs += PAGE_SIZE) { u64 virt_addr = (u64)ipz_qeit_calc(queue, ofs); page = virt_to_page(virt_addr); - rc = vm_insert_page(vma, start, page); - if (unlikely(rc)) { - ehca_gen_err("vm_insert_page() failed rc=%x", rc); - return rc; + ret = vm_insert_page(vma, start, page); + if (unlikely(ret)) { + ehca_gen_err("vm_insert_page() failed rc=%x", ret); + return ret; } start += PAGE_SIZE; } + vma->vm_private_data = mm_count; + (*mm_count)++; + vma->vm_ops = &vm_ops; + + return 0; +} + +static int ehca_mmap_cq(struct vm_area_struct *vma, struct ehca_cq *cq, + u32 rsrc_type) +{ + int ret; + + switch (rsrc_type) { + case 1: /* galpa fw handle */ + ehca_dbg(cq->ib_cq.device, "cq_num=%x fw", cq->cq_number); + ret = ehca_mmap_fw(vma, &cq->galpas, &cq->mm_count_galpa); + if (unlikely(ret)) { + ehca_err(cq->ib_cq.device, +"ehca_mmap_fw() failed rc=%x cq_num=%x", +ret, cq->cq_number); + return ret; + } + break; + + case 2: /* cq queue_addr */ + ehca_dbg(cq->ib_cq.device, "cq_num=%x queue", cq->cq_number); + ret = ehca_mmap_queue(vma, &cq->ipz_queue, &cq->mm_count_queue); + if (unlikely(ret)) { + ehca_err(cq->ib_cq.device, +
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
On Jan 17, 2007, at 5:02 PM, Sasha Khapyorsky wrote: >> 1. Putting the MPI release in git provides a level of OFED-specific >> history and version control. This was explicitly stated on the call >> yesterday. > > Which history information we are expecting to see between bin-file- > ver1 > and bin-file-ver2, where files bin-file-ver* are never changed? I think the point is when they *do* change. >> 2. MPI's have concrete "releases" to OFED just like all other ULP's, >> especially if there is any OFED-specific packaging involved in the >> MPI's release. This was not stated on the call, but it makes sense >> to me. >> >> 3. Putting everything in git makes it nicely uniform for OFED to be >> assembled. This was not stated on the call, and I'm sure it's not a >> requirement, but it is a little nice to be uniform when assembling >> OFED (my $0.02). >> >> 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior >> OFED release processes, > > Yes, and it was bad practice IMO. GIT and SVN are version tracking > tools, > mostly usable for sources and not for compilation results. Why one > should install git if everything really needed is just to download > file > from the server? The SRPMs are not compilation results. Putting compilation results in a version tracking tool would be useless, I agree. >> so putting them in a git seems to parallel >> that procedure. > > Just file hosting should be perfectly enough for the all above. I > don't > see any real reason to use git as non-versioned binary files storage. I think the point was that you could then get a definitive set of files that were shipped in OFED version x.y -- you could accurately rebuild OFED regardless of what files are hosted on the other open source web sites. A perfect example is that the MVAPICH1 package in OFED is prepared by Mellanox, not OSU. So there was no web site to make that tarball and support files available from. Another example is that open source projects may decide to no longer host older versions of their software -- OFA may not be able to control that. The point here is that version control principles apply to binaries just as well as they apply to sources (indeed, the files we're talking about here are binary bundles of sources). Just my $0.02. :-) -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [libibverbs/examples] [PATCH] Added checks to memory allocation failure when using asprintf in pingpong tests
Thanks, applied. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
On 13:34 Tue 16 Jan , Jeff Squyres wrote: > FWIW, having git's for the MPI implementations was asked for on the > call yesterday (by Tziporet, IIRC?). The rationale, as I understood > it, was threefold: > > 1. Putting the MPI release in git provides a level of OFED-specific > history and version control. This was explicitly stated on the call > yesterday. Which history information we are expecting to see between bin-file-ver1 and bin-file-ver2, where files bin-file-ver* are never changed? > 2. MPI's have concrete "releases" to OFED just like all other ULP's, > especially if there is any OFED-specific packaging involved in the > MPI's release. This was not stated on the call, but it makes sense > to me. > > 3. Putting everything in git makes it nicely uniform for OFED to be > assembled. This was not stated on the call, and I'm sure it's not a > requirement, but it is a little nice to be uniform when assembling > OFED (my $0.02). > > 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior > OFED release processes, Yes, and it was bad practice IMO. GIT and SVN are version tracking tools, mostly usable for sources and not for compilation results. Why one should install git if everything really needed is just to download file from the server? > so putting them in a git seems to parallel > that procedure. Just file hosting should be perfectly enough for the all above. I don't see any real reason to use git as non-versioned binary files storage. Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] OFED1.1 and Fed core 6 install question
When trying to install OFED1.1 on my completely updated AMD 64bit Fedora core 6 machine I can't get past the following error. ERROR: The sysfsutils-devel package is required to build libibverbs_devel RPM I have tried a custom install and not selecting libibverbs_devel but it to to use it anyway. Even the basic install selects it. I have all these RPMs installed libsysfs-2.0.0-6 sysfsutils-2.1.0-1 sysfsutils-debuginfo-2.1.0 libsysfs-devel-2.0.0-6 But no where on RPMfind or the rest of the net do I find sysfsutils-devel for Fedora core 6 X86_64. Even when I build sysfs from the tar ball I don't get a sysfsutils-devel Ideas ?? thanks parks -- parks fields <[EMAIL PROTECTED]> HPC-5 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Using GM + OpenIB in the same process at the same time.
[adding openib-general CC] > I have a question about using GM + OpenIB at the same time, it seems > to be causing bad things to happen (process goes into state D) :-). > Here is the issue: > In Open MPI we allow striping of an MPI message across multiple > interconnects at once. In this case I am using GM and OpenIB. This is > using an RDMA pipeline protocol which attempts to overlap > registration and communication (RDMA Write). In the protocol the > target registers a chunk of the message and sends an RDMA Write > request to the origin, the origin then registers the corresponding > chunk of memory and initiates an RDMA Write. Upon completion of the > RDMA Write an RDMA FIN message is sent from the origin to the target. > The target is allowed to have 4 RDMA Write requests outstanding at > any time. > As an example, lets say that the user buffer extends from address 3 > through 12200. The target begins by registering lets say address 3 - > 8000 with OpenIB, under the covers the addresses are page aligned so > we actually register from 0 through 8191. An RDMA Write request is > sent to the origin, note that the origin will only RDMA Write into > addresses 3 - 8000. > The target then begins registering address 8001 through 12200 with > GM, again under the covers the addresses are page aligned so we > actually register from 4096 through 12287 and send an RDMA Write > request to the origin. Again note that the origin will only RDMA > Write into address 8001 through 12200. > > The problem is that when this occurs the process goes into D state > (uninterruptible sleep). After this occurs I am still able to use GM > and OpenIB individually and can even attempt to use them together > (with the result of the process again going into state D). Finding out where the process is sleeping would probably be useful. You can do "cat /proc//wchan" to get a little info. Even better would be to to "echo t > /proc/sysrq-trigger" and send the complete kernel log messages that that produces (and also include the PID that is stuck in uninterruptible sleep). However I think it will probably be up to myricom to debug this in the end -- my ability to figure out what's happening is very limited without the GM sources, and I'm not that interested in debugging someone else's proprietary software anyway. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
> Quoting Or Gerlitz <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 > teleconference about OFED 1.2 development progress toward code freeze > > On 1/17/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > > > Quoting Or Gerlitz <[EMAIL PROTECTED]>: > > > > I understand that the change involves letting the rdma cm know the SID > > > when the consumer calls --rdma_resolve_route-- where today it get to > > > know the SID when the consumer calls --rdma_connect-- . So this is not > > > an internal RDMA CM change but rather also changes the API. > > > > Same for SRP as the api of ib_sa_path_rec_get (that is the structure it > > > gets as input) changes, the SRP code also changes. > > > > Any, can you send the mthca and rdmacm/rdmacm-consumers changes as > > > RFC/PATCH over the list before the actual code freeze??? > > > I didn't start on this code yet, but it does not look like a > > huge project, I hope to post code by next week. > > > To avoid major disruptions all over the stack, my preference for OFED 1.2 > > would be to add new API calls and a module option (off by default) for > > cma/srp > > to use them. > > the rdmacm api change is not such a big deal and if you want to change > it only for the kernel portion for the ofed 1.2 it makes sense to me. > I really don't think --adding-- a special api is the way to go. Doing > it in "end in mind" fashion, work on a patch, send it to the rdmacm > maintainer/list for RFC and so on. > > > For OFED 1.2, I only planned to implement this for SDP and SRP. > > I do not expect all this to be mergeable in 2.6.21 time frame, > > so maybe that's enough. > > SDP is coded over the RDMA CM and i say above my suggestion is not to > add a special API, so just dp the same QoS patching you do to SDP to > iSER etc. Sounds too risky to me, this is technology preview code so I want to have all this stuff off by default but easily enabled by users who want to demo. After I post the rest of the code, if you like you'll be able to post an iser patch to add this stuff to iser as well. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] SVN deprication
Thanks Jeff. This works. 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: Jeff Squyres [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 3:30 PM > To: Kanevsky, Arkady > Cc: openib-general@openib.org > Subject: Re: [openib-general] SVN deprication > > SVN is still available, but it is at a new URL: > > https://svn.openfabrics.org/svn/openib. > > All the history and everything should be there; let me know > if you have any problems. > > > On Jan 17, 2007, at 3:11 PM, Arkady Kanevsky wrote: > > > Jeff and Co, > > Is there a way to find out the date of a specific SVN revision #? > > I can no longer access svn: > > svn info -r 5400 https://openfabric.org/svn > > svn: PROPFIND request failed on '/svn' > > svn: PROPFIND of '/svn': could not connect to server (https:// > > openfabric.org) > > > > Is the SVN server depricated for good? > > Do we have an SVN log somewhere in a git? > > If yes, how can I find the correlation between Linux > version and SVN > > revision? > > Thanks, > > Arkady > > > > ___ > > openib-general mailing list > > openib-general@openib.org > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit http://openib.org/mailman/listinfo/ > > openib-general > > > -- > Jeff Squyres > Server Virtualization Business Unit > Cisco Systems > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] SDP performance
> Can any of the SDP developers confirm that SDP can be zero-copy both on > sending and receiving? If so, are there tunables that affect when to copy > and when not? Our SDP does not support zero-copy on either end at the moment. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] SVN deprication
SVN is still available, but it is at a new URL: https://svn.openfabrics.org/svn/openib. All the history and everything should be there; let me know if you have any problems. On Jan 17, 2007, at 3:11 PM, Arkady Kanevsky wrote: > Jeff and Co, > Is there a way to find out the date of a specific SVN revision #? > I can no longer access svn: > svn info -r 5400 https://openfabric.org/svn > svn: PROPFIND request failed on '/svn' > svn: PROPFIND of '/svn': could not connect to server (https:// > openfabric.org) > > Is the SVN server depricated for good? > Do we have an SVN log somewhere in a git? > If yes, how can I find the correlation between Linux version and > SVN revision? > Thanks, > Arkady > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/ > openib-general -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH RFC 00/21] ofed_1_2 - Chelsio Backport to SLES9SP3
> Quoting Steve WIse <[EMAIL PROTECTED]>: > Subject: Re: [PATCH RFC 00/21] ofed_1_2 - Chelsio Backport to SLES9SP3 > > > BTW, Steve, I wouldn't start working on backports from SLES9. > > I'd start with 2.6.19 and go back to 2.6.11 over kernel.org versions, > > just making sure they build (we have this build environment on > > openfabrics.org, > > or its easy to check all versions out from kernel.org git). > > In this way you get incrementtall a host of data on what is and what isn't > > in > > which kernel version. > > > > Then adding support for a distro is just a matter of finding a closest > > kernel.org kernel and mostly removing stuff that distro backported from > > newer kernels. > > > > Michael, > > Is there something magic about stopping at 2.6.11? Yes. AFAIK IB subsystem was added to upstream kernel in 2.6.11. So our kernel.org support has grown historically from there, and we just added a couple of older distro kernels. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] SVN deprication
Jeff and Co, Is there a way to find out the date of a specific SVN revision #? I can no longer access svn: svn info -r 5400 https://openfabric.org/svn svn: PROPFIND request failed on '/svn' svn: PROPFIND of '/svn': could not connect to server (https://openfabric.org) Is the SVN server depricated for good? Do we have an SVN log somewhere in a git? If yes, how can I find the correlation between Linux version and SVN revision? Thanks, Arkady ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH RFC 09/10] ofed_1_2 Backport Chelsio to 2.6.11
Backport Chelsio to 2.6.11 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.11/include/linux/ethtool.h|9 + .../backport/2.6.11/include/linux/genalloc.h | 42 + .../backport/2.6.11/include/linux/interrupt.h | 17 ++ kernel_addons/backport/2.6.11/include/linux/mm.h |8 + .../backport/2.6.11/include/linux/netdevice.h |9 + .../backport/2.6.11/include/linux/random.h | 15 ++ .../backport/2.6.11/include/linux/skbuff.h |2 kernel_addons/backport/2.6.11/include/linux/slab.h | 19 -- .../backport/2.6.11/include/linux/types.h |2 .../backport/2.6.11/include/linux/workqueue.h |8 + kernel_addons/backport/2.6.11/include/net/dst.h| 16 ++ .../backport/2.6.11/include/net/netevent.h | 33 .../backport/2.6.11/include/src/genalloc.c | 198 +++ .../backport/2.6.11/include/src/netevent.c | 71 .../backport/2.6.11/cxgb3_main_to_2_6_13.patch | 12 + .../backport/2.6.11/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.11/linux_stuff_to_2_6_17.patch| 24 +++ .../2.6.11/mthca_provider_3465_to_2_6_11.patch | 13 -- .../backport/2.6.11/t3_hw_to_2_6_13.patch | 13 ++ 19 files changed, 492 insertions(+), 31 deletions(-) diff --git a/kernel_addons/backport/2.6.11/include/linux/ethtool.h b/kernel_addons/backport/2.6.11/include/linux/ethtool.h new file mode 100644 index 000..d03127c --- /dev/null +++ b/kernel_addons/backport/2.6.11/include/linux/ethtool.h @@ -0,0 +1,9 @@ +#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13 +#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13 + +#include_next + +#define ADVERTISED_Pause (1 << 13) +#define ADVERTISED_Asym_Pause (1 << 14) + +#endif diff --git a/kernel_addons/backport/2.6.11/include/linux/genalloc.h b/kernel_addons/backport/2.6.11/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.11/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.11/include/linux/interrupt.h b/kernel_addons/backport/2.6.11/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.11/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.11/include/linux/mm.h b/kernel_addons/backport/2.6.11/include/linux/mm.h new file mode 100644 index 000..1a1cf11 --- /dev/null +++ b/kernel_addons/backport/2.6.11/include/linux/mm.h @@ -0,0 +1,8 @@ +#ifndef BACKPORT_LINUX_MM_TO_2_6_11 +#define BACKPORT_LINUX_MM_TO_2_6_11 + +#include_next + +#define io_remap_pfn_range remap_pfn_range + +#endif diff --git a/kernel_addons/backport/2.6.11/include/linux/netdevice.h b/kernel_addons/backport/2.6.11/include/linux/netdevice.h index 5641019..2f12781 100644 --- a/kerne
[openib-general] [PATCH RFC 10/10] ofed_1_2 Backport Chelsio to sles9sp3
Backport Chelsio to sles9sp3 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../2.6.5_sles9_sp3/include/linux/ethtool.h|9 + .../2.6.5_sles9_sp3/include/linux/genalloc.h | 42 + .../2.6.5_sles9_sp3/include/linux/interrupt.h | 17 ++ .../backport/2.6.5_sles9_sp3/include/linux/kfifo.h | 157 ++ .../backport/2.6.5_sles9_sp3/include/linux/mii.h | 18 ++ .../backport/2.6.5_sles9_sp3/include/linux/mm.h| 20 ++ .../2.6.5_sles9_sp3/include/linux/netdevice.h | 13 ++ .../backport/2.6.5_sles9_sp3/include/linux/pci.h |2 .../2.6.5_sles9_sp3/include/linux/random.h | 15 ++ .../2.6.5_sles9_sp3/include/linux/skbuff.h |3 .../backport/2.6.5_sles9_sp3/include/linux/slab.h | 19 -- .../2.6.5_sles9_sp3/include/linux/spinlock.h |8 + .../backport/2.6.5_sles9_sp3/include/linux/types.h |2 .../2.6.5_sles9_sp3/include/linux/workqueue.h |8 + .../backport/2.6.5_sles9_sp3/include/net/dst.h | 17 ++ .../2.6.5_sles9_sp3/include/net/neighbour.h|7 + .../2.6.5_sles9_sp3/include/net/netevent.h | 33 .../2.6.5_sles9_sp3/include/src/genalloc.c | 198 +++ .../backport/2.6.5_sles9_sp3/include/src/kfifo.c | 196 +++ .../2.6.5_sles9_sp3/include/src/netevent.c | 71 .../2.6.5_sles9_sp3/cxgb3_main_to_2_6_13.patch | 12 + .../2.6.5_sles9_sp3/cxgb3_makefile_to_2_6_19.patch | 12 + .../2.6.5_sles9_sp3/iwch_cm_to_2_6_5-7_244.patch | 35 .../linux_stream_idr_to_2_6_5-7_244.patch | 25 --- .../linux_stuff_to_2_6_5-7_244.patch | 46 + .../mthca_provider_3465_to_2_6_9.patch | 15 -- .../2.6.5_sles9_sp3/t3_hw_to_2_6_5-7_244.patch | 43 + 27 files changed, 985 insertions(+), 58 deletions(-) diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/ethtool.h b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/ethtool.h new file mode 100644 index 000..d03127c --- /dev/null +++ b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/ethtool.h @@ -0,0 +1,9 @@ +#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13 +#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13 + +#include_next + +#define ADVERTISED_Pause (1 << 13) +#define ADVERTISED_Asym_Pause (1 << 14) + +#endif diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/genalloc.h b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/interrupt.h b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.5_sles9_sp3/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev
[openib-general] [PATCH RFC 07/10] ofed_1_2 Backport Chelsio to 2.6.13
Backport Chelsio to 2.6.13 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.13/include/linux/ethtool.h|9 + .../backport/2.6.13/include/linux/genalloc.h | 42 + .../backport/2.6.13/include/linux/interrupt.h | 17 ++ .../backport/2.6.13/include/linux/netdevice.h |9 + .../backport/2.6.13/include/linux/random.h | 15 ++ .../backport/2.6.13/include/linux/skbuff.h |3 .../backport/2.6.13/include/linux/types.h |2 .../backport/2.6.13/include/linux/workqueue.h |9 + .../backport/2.6.13/include/net/netevent.h | 33 .../backport/2.6.13/include/src/genalloc.c | 198 +++ .../backport/2.6.13/include/src/netevent.c | 71 .../backport/2.6.13/cxgb3_main_to_2_6_13.patch | 12 + .../backport/2.6.13/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.13/linux_stuff_to_2_6_17.patch| 24 +++ .../backport/2.6.13/t3_hw_to_2_6_13.patch | 13 ++ 15 files changed, 468 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.13/include/linux/ethtool.h b/kernel_addons/backport/2.6.13/include/linux/ethtool.h new file mode 100644 index 000..d03127c --- /dev/null +++ b/kernel_addons/backport/2.6.13/include/linux/ethtool.h @@ -0,0 +1,9 @@ +#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13 +#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13 + +#include_next + +#define ADVERTISED_Pause (1 << 13) +#define ADVERTISED_Asym_Pause (1 << 14) + +#endif diff --git a/kernel_addons/backport/2.6.13/include/linux/genalloc.h b/kernel_addons/backport/2.6.13/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.13/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.13/include/linux/interrupt.h b/kernel_addons/backport/2.6.13/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.13/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.13/include/linux/netdevice.h b/kernel_addons/backport/2.6.13/include/linux/netdevice.h index 5641019..2f12781 100644 --- a/kernel_addons/backport/2.6.13/include/linux/netdevice.h +++ b/kernel_addons/backport/2.6.13/include/linux/netdevice.h @@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc spin_unlock(&dev->xmit_lock); } +static inline int __netif_rx_schedule_prep(struct net_device *dev) +{ +return !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state); +} + +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + #endif diff --git a/kernel_addons/backport/2.6.13/include/linux/random.h b/kernel_addons/backport/2.6.13/include/linux/random.h new file mode 100644
[openib-general] [PATCH RFC 05/10] ofed_1_2 Backport cxgb3 to 2.6.15
Backport cxgb3 to 2.6.15 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.15/include/linux/genalloc.h | 42 + .../backport/2.6.15/include/linux/interrupt.h | 17 ++ .../backport/2.6.15/include/linux/netdevice.h |9 + .../backport/2.6.15/include/linux/random.h | 15 ++ .../backport/2.6.15/include/linux/skbuff.h |3 .../backport/2.6.15/include/linux/types.h |6 + .../backport/2.6.15/include/linux/workqueue.h |9 + .../backport/2.6.15/include/net/netevent.h | 33 .../backport/2.6.15/include/src/genalloc.c | 198 +++ .../backport/2.6.15/include/src/netevent.c | 71 .../backport/2.6.15/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.15/linux_stuff_to_2_6_17.patch| 24 +++ 12 files changed, 438 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.15/include/linux/genalloc.h b/kernel_addons/backport/2.6.15/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.15/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.15/include/linux/interrupt.h b/kernel_addons/backport/2.6.15/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.15/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.15/include/linux/netdevice.h b/kernel_addons/backport/2.6.15/include/linux/netdevice.h index 5641019..2f12781 100644 --- a/kernel_addons/backport/2.6.15/include/linux/netdevice.h +++ b/kernel_addons/backport/2.6.15/include/linux/netdevice.h @@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc spin_unlock(&dev->xmit_lock); } +static inline int __netif_rx_schedule_prep(struct net_device *dev) +{ +return !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state); +} + +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + #endif diff --git a/kernel_addons/backport/2.6.15/include/linux/random.h b/kernel_addons/backport/2.6.15/include/linux/random.h new file mode 100644 index 000..2ea2e1f --- /dev/null +++ b/kernel_addons/backport/2.6.15/include/linux/random.h @@ -0,0 +1,15 @@ +#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18 +#define BACKPORT_LINUX_RANDOM_TO_2_6_18 +#include_next + +static inline u32 backport_random32(void) +{ + u32 v; + + get_random_bytes(&v, sizeof(u32)); + return v; +} + +#define random32 backport_random32 + +#endif diff --git a/kernel_addons/backport/2.6.15/include/linux/skbuff.h b/kernel_addons/backport/2.6.15/include/linux/skbuff.h index 4845283..70bf011 100644 --- a/kernel_addons/backport/2.6.15/include/linux/skbuff.h +++ b/kernel_addons/backport/2.6.15/include/linux/skbuff.
[openib-general] [PATCH RFC 08/10] ofed_1_2 Backport Chelsio to 2.6.12
Backport Chelsio to 2.6.12 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.12/include/linux/ethtool.h|9 + .../backport/2.6.12/include/linux/genalloc.h | 42 + .../backport/2.6.12/include/linux/interrupt.h | 17 ++ .../backport/2.6.12/include/linux/netdevice.h |9 + .../backport/2.6.12/include/linux/random.h | 15 ++ .../backport/2.6.12/include/linux/skbuff.h |3 .../backport/2.6.12/include/linux/types.h |2 .../backport/2.6.12/include/linux/workqueue.h |9 + .../backport/2.6.12/include/net/netevent.h | 33 .../backport/2.6.12/include/src/genalloc.c | 198 +++ .../backport/2.6.12/include/src/netevent.c | 71 .../backport/2.6.12/cxgb3_main_to_2_6_13.patch | 12 + .../backport/2.6.12/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.12/linux_stuff_to_2_6_17.patch| 24 +++ .../backport/2.6.12/t3_hw_to_2_6_13.patch | 13 ++ 15 files changed, 468 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.12/include/linux/ethtool.h b/kernel_addons/backport/2.6.12/include/linux/ethtool.h new file mode 100644 index 000..d03127c --- /dev/null +++ b/kernel_addons/backport/2.6.12/include/linux/ethtool.h @@ -0,0 +1,9 @@ +#ifndef BACKPORT_LINUX_ETHTOOL_TO_2_6_13 +#define BACKPORT_LINUX_ETHTOOL_TO_2_6_13 + +#include_next + +#define ADVERTISED_Pause (1 << 13) +#define ADVERTISED_Asym_Pause (1 << 14) + +#endif diff --git a/kernel_addons/backport/2.6.12/include/linux/genalloc.h b/kernel_addons/backport/2.6.12/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.12/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.12/include/linux/interrupt.h b/kernel_addons/backport/2.6.12/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.12/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.12/include/linux/netdevice.h b/kernel_addons/backport/2.6.12/include/linux/netdevice.h index 5641019..2f12781 100644 --- a/kernel_addons/backport/2.6.12/include/linux/netdevice.h +++ b/kernel_addons/backport/2.6.12/include/linux/netdevice.h @@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc spin_unlock(&dev->xmit_lock); } +static inline int __netif_rx_schedule_prep(struct net_device *dev) +{ +return !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state); +} + +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + #endif diff --git a/kernel_addons/backport/2.6.12/include/linux/random.h b/kernel_addons/backport/2.6.12/include/linux/random.h new file mode 100644
[openib-general] [PATCH RFC 06/10] ofed_1_2 Backport chelsio to 2.6.14
Backport chelsio to 2.6.14 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.14/include/linux/genalloc.h | 42 + .../backport/2.6.14/include/linux/interrupt.h | 17 ++ .../backport/2.6.14/include/linux/netdevice.h |9 + .../backport/2.6.14/include/linux/random.h | 15 ++ .../backport/2.6.14/include/linux/skbuff.h |3 .../backport/2.6.14/include/linux/types.h |6 + .../backport/2.6.14/include/linux/workqueue.h |9 + .../backport/2.6.14/include/net/netevent.h | 33 .../backport/2.6.14/include/src/genalloc.c | 198 +++ .../backport/2.6.14/include/src/netevent.c | 71 .../backport/2.6.14/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.14/linux_stuff_to_2_6_17.patch| 24 +++ 12 files changed, 438 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.14/include/linux/genalloc.h b/kernel_addons/backport/2.6.14/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.14/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.14/include/linux/interrupt.h b/kernel_addons/backport/2.6.14/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.14/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.14/include/linux/netdevice.h b/kernel_addons/backport/2.6.14/include/linux/netdevice.h index 5641019..2f12781 100644 --- a/kernel_addons/backport/2.6.14/include/linux/netdevice.h +++ b/kernel_addons/backport/2.6.14/include/linux/netdevice.h @@ -15,4 +15,13 @@ static inline void netif_tx_unlock(struc spin_unlock(&dev->xmit_lock); } +static inline int __netif_rx_schedule_prep(struct net_device *dev) +{ +return !test_and_set_bit(__LINK_STATE_RX_SCHED, &dev->state); +} + +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + #endif diff --git a/kernel_addons/backport/2.6.14/include/linux/random.h b/kernel_addons/backport/2.6.14/include/linux/random.h new file mode 100644 index 000..2ea2e1f --- /dev/null +++ b/kernel_addons/backport/2.6.14/include/linux/random.h @@ -0,0 +1,15 @@ +#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18 +#define BACKPORT_LINUX_RANDOM_TO_2_6_18 +#include_next + +static inline u32 backport_random32(void) +{ + u32 v; + + get_random_bytes(&v, sizeof(u32)); + return v; +} + +#define random32 backport_random32 + +#endif diff --git a/kernel_addons/backport/2.6.14/include/linux/skbuff.h b/kernel_addons/backport/2.6.14/include/linux/skbuff.h index 4845283..70bf011 100644 --- a/kernel_addons/backport/2.6.14/include/linux/skbuff.h +++ b/kernel_addons/backport/2.6.14/include/linux/skbuf
[openib-general] [PATCH RFC 03/10] ofed_1_2 Chelsio backport to 2.6.17
Chelsio backport to 2.6.17 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.17/include/linux/genalloc.h | 42 + .../backport/2.6.17/include/linux/interrupt.h | 17 ++ .../backport/2.6.17/include/linux/netdevice.h |4 .../backport/2.6.17/include/linux/random.h | 15 ++ .../backport/2.6.17/include/linux/skbuff.h |3 .../backport/2.6.17/include/linux/workqueue.h |9 + .../backport/2.6.17/include/net/netevent.h | 33 .../backport/2.6.17/include/src/genalloc.c | 198 +++ .../backport/2.6.17/include/src/netevent.c | 69 .../backport/2.6.17/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.17/linux_stuff_to_2_6_17.patch| 24 +++ 11 files changed, 425 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.17/include/linux/genalloc.h b/kernel_addons/backport/2.6.17/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.17/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.17/include/linux/interrupt.h b/kernel_addons/backport/2.6.17/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.17/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.17/include/linux/netdevice.h b/kernel_addons/backport/2.6.17/include/linux/netdevice.h index 5641019..225eeda 100644 --- a/kernel_addons/backport/2.6.17/include/linux/netdevice.h +++ b/kernel_addons/backport/2.6.17/include/linux/netdevice.h @@ -15,4 +15,8 @@ static inline void netif_tx_unlock(struc spin_unlock(&dev->xmit_lock); } +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + #endif diff --git a/kernel_addons/backport/2.6.17/include/linux/random.h b/kernel_addons/backport/2.6.17/include/linux/random.h new file mode 100644 index 000..2ea2e1f --- /dev/null +++ b/kernel_addons/backport/2.6.17/include/linux/random.h @@ -0,0 +1,15 @@ +#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18 +#define BACKPORT_LINUX_RANDOM_TO_2_6_18 +#include_next + +static inline u32 backport_random32(void) +{ + u32 v; + + get_random_bytes(&v, sizeof(u32)); + return v; +} + +#define random32 backport_random32 + +#endif diff --git a/kernel_addons/backport/2.6.17/include/linux/skbuff.h b/kernel_addons/backport/2.6.17/include/linux/skbuff.h index 4845283..70bf011 100644 --- a/kernel_addons/backport/2.6.17/include/linux/skbuff.h +++ b/kernel_addons/backport/2.6.17/include/linux/skbuff.h @@ -4,5 +4,8 @@ #define LINUX_SKBUFF_H_BACKPORT #include_next #define CHECKSUM_PARTIAL CHECKSUM_HW +#define CHECKSUM_COMPLETE CHECKSUM_HW + +#define gso_size tso_size #endif diff --git a/kernel_ad
[openib-general] [PATCH RFC 02/10] ofed_1_2 Chelsio backport to 2.6.18
Chelsio backport to 2.6.18 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.18/include/linux/genalloc.h | 42 + .../backport/2.6.18/include/linux/interrupt.h | 17 ++ .../backport/2.6.18/include/linux/netdevice.h |9 + .../backport/2.6.18/include/linux/random.h | 15 ++ .../backport/2.6.18/include/linux/skbuff.h |1 .../backport/2.6.18/include/linux/workqueue.h |9 + .../backport/2.6.18/include/src/genalloc.c | 198 +++ .../backport/2.6.18/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.18/linux_genalloc_to_2_6_20.patch | 17 ++ 9 files changed, 319 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.18/include/linux/genalloc.h b/kernel_addons/backport/2.6.18/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.18/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.18/include/linux/interrupt.h b/kernel_addons/backport/2.6.18/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.18/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.18/include/linux/netdevice.h b/kernel_addons/backport/2.6.18/include/linux/netdevice.h new file mode 100644 index 000..61a6deb --- /dev/null +++ b/kernel_addons/backport/2.6.18/include/linux/netdevice.h @@ -0,0 +1,9 @@ +#ifndef BACKPORT_LINUX_NETDEVICE_TO_2_6_18 +#define BACKPORT_LINUX_NETDEVICE_TO_2_6_18 +#include_next + +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + +#endif diff --git a/kernel_addons/backport/2.6.18/include/linux/random.h b/kernel_addons/backport/2.6.18/include/linux/random.h new file mode 100644 index 000..2ea2e1f --- /dev/null +++ b/kernel_addons/backport/2.6.18/include/linux/random.h @@ -0,0 +1,15 @@ +#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18 +#define BACKPORT_LINUX_RANDOM_TO_2_6_18 +#include_next + +static inline u32 backport_random32(void) +{ + u32 v; + + get_random_bytes(&v, sizeof(u32)); + return v; +} + +#define random32 backport_random32 + +#endif diff --git a/kernel_addons/backport/2.6.18/include/linux/skbuff.h b/kernel_addons/backport/2.6.18/include/linux/skbuff.h index 4845283..ca5edc0 100644 --- a/kernel_addons/backport/2.6.18/include/linux/skbuff.h +++ b/kernel_addons/backport/2.6.18/include/linux/skbuff.h @@ -4,5 +4,6 @@ #define LINUX_SKBUFF_H_BACKPORT #include_next #define CHECKSUM_PARTIAL CHECKSUM_HW +#define CHECKSUM_COMPLETE CHECKSUM_HW #endif diff --git a/kernel_addons/backport/2.6.18/include/linux/workqueue.h b/kernel_addons/backport/2.6.18/include/linux/workqueue.h index 330f47f..cc8b2cd 100644 --- a/kernel_addons/backport/2.6.18/incl
[openib-general] [PATCH RFC 04/10] ofed_1_2 Chelsio backport to 2.6.16
Chelsio backport to 2.6.16 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.16/include/linux/genalloc.h | 42 + .../backport/2.6.16/include/linux/interrupt.h | 17 ++ .../backport/2.6.16/include/linux/netdevice.h |4 .../backport/2.6.16/include/linux/random.h | 15 ++ .../backport/2.6.16/include/linux/skbuff.h |3 .../backport/2.6.16/include/linux/workqueue.h |9 + .../backport/2.6.16/include/net/netevent.h | 33 .../backport/2.6.16/include/src/genalloc.c | 198 +++ .../backport/2.6.16/include/src/netevent.c | 71 .../backport/2.6.16/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.16/linux_stuff_to_2_6_17.patch| 24 +++ 11 files changed, 427 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.16/include/linux/genalloc.h b/kernel_addons/backport/2.6.16/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.16/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.16/include/linux/interrupt.h b/kernel_addons/backport/2.6.16/include/linux/interrupt.h new file mode 100644 index 000..66e66a9 --- /dev/null +++ b/kernel_addons/backport/2.6.16/include/linux/interrupt.h @@ -0,0 +1,17 @@ +#ifndef BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#define BACKPORT_LINUX_INTERRUPT_TO_2_6_18 +#include_next + +static inline int +backport_request_irq(unsigned int irq, + irqreturn_t (*handler)(int, void *), + unsigned long flags, const char *dev_name, void *dev_id) +{ + return request_irq(irq, + (irqreturn_t (*)(int, void *, struct pt_regs *))handler, + flags, dev_name, dev_id); +} + +#define request_irq backport_request_irq + +#endif diff --git a/kernel_addons/backport/2.6.16/include/linux/netdevice.h b/kernel_addons/backport/2.6.16/include/linux/netdevice.h index 5641019..225eeda 100644 --- a/kernel_addons/backport/2.6.16/include/linux/netdevice.h +++ b/kernel_addons/backport/2.6.16/include/linux/netdevice.h @@ -15,4 +15,8 @@ static inline void netif_tx_unlock(struc spin_unlock(&dev->xmit_lock); } +#undef SET_ETHTOOL_OPS +#define SET_ETHTOOL_OPS(netdev, ops) \ + (netdev)->ethtool_ops = (struct ethtool_ops *)(ops) + #endif diff --git a/kernel_addons/backport/2.6.16/include/linux/random.h b/kernel_addons/backport/2.6.16/include/linux/random.h new file mode 100644 index 000..2ea2e1f --- /dev/null +++ b/kernel_addons/backport/2.6.16/include/linux/random.h @@ -0,0 +1,15 @@ +#ifndef BACKPORT_LINUX_RANDOM_TO_2_6_18 +#define BACKPORT_LINUX_RANDOM_TO_2_6_18 +#include_next + +static inline u32 backport_random32(void) +{ + u32 v; + + get_random_bytes(&v, sizeof(u32)); + return v; +} + +#define random32 backport_random32 + +#endif diff --git a/kernel_addons/backport/2.6.16/include/linux/skbuff.h b/kernel_addons/backport/2.6.16/include/linux/skbuff.h index 4845283..70bf011 100644 --- a/kernel_addons/backport/2.6.16/include/linux/skbuff.h +++ b/kernel_addons/backport/2.6.16/include/linux/skbuff.h @@ -4,5 +4,8 @@ #define LINUX_SKBUFF_H_BACKPORT #include_next #define CHECKSUM_PARTIAL CHECKSUM_HW +#define CHECKSUM_COMPLETE CHECKSUM_HW + +#define gso_size tso_size #endif diff --git a/kernel_ad
[openib-general] [PATCH RFC 01/10] ofed_1_2 Chelsio backport to 2.6.19
Chelsio backport to 2.6.19 Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- .../backport/2.6.19/include/linux/genalloc.h | 42 + .../backport/2.6.19/include/linux/workqueue.h |9 + .../backport/2.6.19/include/src/genalloc.c | 198 +++ .../backport/2.6.19/cxgb3_makefile_to_2_6_19.patch | 12 + .../backport/2.6.19/linux_genalloc_to_2_6_20.patch | 17 ++ 5 files changed, 277 insertions(+), 1 deletions(-) diff --git a/kernel_addons/backport/2.6.19/include/linux/genalloc.h b/kernel_addons/backport/2.6.19/include/linux/genalloc.h new file mode 100644 index 000..3c23c68 --- /dev/null +++ b/kernel_addons/backport/2.6.19/include/linux/genalloc.h @@ -0,0 +1,42 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + + +/* + * General purpose special memory pool descriptor. + */ +struct gen_pool { + rwlock_t lock; + struct list_head chunks;/* list of chunks in this pool */ + int min_alloc_order;/* minimum allocation order */ +}; + +/* + * General purpose special memory pool chunk descriptor. + */ +struct gen_pool_chunk { + spinlock_t lock; + struct list_head next_chunk;/* next chunk in pool */ + unsigned long start_addr; /* starting address of memory chunk */ + unsigned long end_addr; /* ending address of memory chunk */ + unsigned long bits[0]; /* bitmap for allocating memory chunk */ +}; + +extern struct gen_pool *ib_gen_pool_create(int, int); +extern int ib_gen_pool_add(struct gen_pool *, unsigned long, size_t, int); +extern void ib_gen_pool_destroy(struct gen_pool *); +extern unsigned long ib_gen_pool_alloc(struct gen_pool *, size_t); +extern void ib_gen_pool_free(struct gen_pool *, unsigned long, size_t); + +#define gen_pool_create ib_gen_pool_create +#define gen_pool_add ib_gen_pool_add +#define gen_pool_destroy ib_gen_pool_destroy +#define gen_pool_alloc ib_gen_pool_alloc +#define gen_pool_free ib_gen_pool_free diff --git a/kernel_addons/backport/2.6.19/include/linux/workqueue.h b/kernel_addons/backport/2.6.19/include/linux/workqueue.h index 330f47f..cc8b2cd 100644 --- a/kernel_addons/backport/2.6.19/include/linux/workqueue.h +++ b/kernel_addons/backport/2.6.19/include/linux/workqueue.h @@ -26,6 +26,12 @@ backport_cancel_delayed_work(struct dela return cancel_delayed_work(&work->work); } +static inline void +backport_cancel_rearming_delayed_workqueue(struct workqueue_struct *wq, struct delayed_work *work) +{ + cancel_rearming_delayed_workqueue(wq, &work->work); +} + #undef INIT_WORK #define INIT_WORK(_work, _func) backport_INIT_WORK(_work, _func) @@ -33,11 +39,12 @@ #define INIT_DELAYED_WORK(_work, _func) #undef DECLARE_WORK #define DECLARE_WORK(n, f) \ - struct work_struct n = __WORK_INITIALIZER(n, f, &(n)) + struct work_struct n = __WORK_INITIALIZER(n, (void (*)(void *))f, &(n)) #define DECLARE_DELAYED_WORK(n, f) \ struct delayed_work n = { .work = __WORK_INITIALIZER(n.work, f, &(n.work)) } #define queue_delayed_work backport_queue_delayed_work #define cancel_delayed_work backport_cancel_delayed_work +#define cancel_rearming_delayed_workqueue backport_cancel_rearming_delayed_workqueue #endif diff --git a/kernel_addons/backport/2.6.19/include/src/genalloc.c b/kernel_addons/backport/2.6.19/include/src/genalloc.c new file mode 100644 index 000..75ae68c --- /dev/null +++ b/kernel_addons/backport/2.6.19/include/src/genalloc.c @@ -0,0 +1,198 @@ +/* + * Basic general purpose allocator for managing special purpose memory + * not managed by the regular kmalloc/kfree interface. + * Uses for this includes on-device special memory, uncached memory + * etc. + * + * Copyright 2005 (C) Jes Sorensen <[EMAIL PROTECTED]> + * + * This source code is licensed under the GNU General Public License, + * Version 2. See the file COPYING for more details. + */ + +#include +#include + + +/** + * gen_pool_create - create a new special memory pool + * @min_alloc_order: log base 2 of number of bytes each bitmap bit represents + * @nid: node id of the node the pool structure should be allocated on, or -1 + * + * Create a new special memory pool that can be used to manage special purpose + * memory not managed by the regular kmalloc/kfree interface. + */ +struct gen_pool *gen_pool_create(int min_alloc_order, int nid) +{ + struct gen_pool *pool; + + pool = kmalloc_node(sizeof(struct gen_pool), GFP_KERNEL, nid); + if (pool != NULL) { + rwlock_init(&pool->lock); + INIT_LIST_HEAD(&pool->chunks); + pool->min_alloc_order = min_alloc_order; + } + return pool; +}
[openib-general] [PATCH RFC 00/10] ofed_1_2 - Chelsio backports
Michael, I took your advice and backported the chelsio code to kernel.org kernels 2.6.19 through 2.6.11 and then to sles9sp3. Attached are the patches, one for each kernel.org version. Please review. Thanks, Steve. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
> makes sense, so my suggestion is "leave this (using the ipoib qkey) to > the user" This is fine, but it may change when the user needs to make this choice. E.g. when creating the QP, versus joining the multicast group, in order to support the valid options. The selection also needs to be conveyed to the kernel somehow. At this point, maybe we just need to start looking at specific implementations. > I don't think there is any limitation today in the verbs layer, > actually for our testing so far we patches the rdmacm not set the sig > byte and use the ipoib (ie not override it in core/cma.c) and we > manage to interop fine with ipoib. Maybe this shouldn't be allowed for any random application. Perhaps there's a way to treat controlled qkeys similar to the privileged port space. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] opensm: fix segfault with up/down and root nodes file.
On Tue, 2007-01-09 at 18:21, Sasha Khapyorsky wrote: > Segfault happens when yet non-initialized lid_matrix tables are > accessed - with up/down routing engine when root nodes are provided by > user and lid matrices are not pre-created. There is the fix. > > Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]> Thanks. Applied. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
On 1/17/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > > Quoting Or Gerlitz <[EMAIL PROTECTED]>: > > I understand that the change involves letting the rdma cm know the SID > > when the consumer calls --rdma_resolve_route-- where today it get to > > know the SID when the consumer calls --rdma_connect-- . So this is not > > an internal RDMA CM change but rather also changes the API. > > Same for SRP as the api of ib_sa_path_rec_get (that is the structure it > > gets as input) changes, the SRP code also changes. > > Any, can you send the mthca and rdmacm/rdmacm-consumers changes as > > RFC/PATCH over the list before the actual code freeze??? > I didn't start on this code yet, but it does not look like a > huge project, I hope to post code by next week. > To avoid major disruptions all over the stack, my preference for OFED 1.2 > would be to add new API calls and a module option (off by default) for cma/srp > to use them. the rdmacm api change is not such a big deal and if you want to change it only for the kernel portion for the ofed 1.2 it makes sense to me. I really don't think --adding-- a special api is the way to go. Doing it in "end in mind" fashion, work on a patch, send it to the rdmacm maintainer/list for RFC and so on. > For OFED 1.2, I only planned to implement this for SDP and SRP. > I do not expect all this to be mergeable in 2.6.21 time frame, > so maybe that's enough. SDP is coded over the RDMA CM and i say above my suggestion is not to add a special API, so just dp the same QoS patching you do to SDP to iSER etc. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
On 1/17/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > > +1 used only for unicast > > +2 used only for multicast > > +3 used for both unicast and multicast > If you view this as the use case for one side only, we also have option 3 > communicating with options 1 and 2. I would list these as: OK > +4 unicast QP to unicast and multicast QP i think you mean 3 <--> 1 that is unicast and multicast QP to unicast QP > +5 multicast QP to unicast and multicast QP i think you mean 3 <--> 2 that is unicast and multicast QP to multicast QP > Today, all of these work. What you're wanting to add is the ability to > communicate with an ipoib multicast group. I'd like to do this without > breaking > any of the existing communications, or treat ipoib separately for security > reasons. makes sense, so my suggestion is "leave this (using the ipoib qkey) to the user" if you prefer to have two group types: rdmacm and ipoib - that's fine. we would use ipoib type groups and in the envs that seting the qkey to be the ipoib would not break our communication (that is where we do need to interop with IPoIB) - we would do it, else we would do nothing. > > To make things simple, the solution i suggest is that that the RDMA CM > > would --not-- do this modify QP/QKEY (that is would set the 0x12345678 > > qkey on the modify qp to init) and rather leave it to the RDMA CM > > consumer --if-- they wish to do so. However it will use the ipv4 > > broadcast group qkey for doing mcast joins and report this qkey to the > > user in the ud param of the event. > > We need to be able to handle options 4 and 5 as well. indeed, i have addressed that above. > > this (what qkey is assigned to the ipv4 broadcast group by different > > SAs) is orthogonal to the discussion we do here. > This depends on whether verbs allows, or if it should allow, a user to > specify a > controlled qkey when configuring their QP. I don't think there is any limitation today in the verbs layer, actually for our testing so far we patches the rdmacm not set the sig byte and use the ipoib (ie not override it in core/cma.c) and we manage to interop fine with ipoib. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
On 1/17/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > > not following you here, how does qkey relates to RC QPs ? > Currently you can block userspace from creating QPs by unloading uverbs > module. > Maybe we should make it possible to block creating UD QPs from userspace > as a separate security measure. I don't think this is valid option for most of the IB production env. but if you want to add blocking UD QP creation to ib_uverbs as mod param whose default value is --unset--, i don't really care. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] SDP performance
Hi, Does anyone have any performance measurements of SDP over OpenFabrics? Can any of the SDP developers confirm that SDP can be zero-copy both on sending and receiving? If so, are there tunables that affect when to copy and when not? Cheers, Eric --- |Eric BartonBarton Software | |9 York Gardens Tel:+44 (117) 330 1575| |CliftonMobile: +44 (7909) 680 356| |Bristol BS8 4LLFax:call first| |United Kingdom E-Mail: [EMAIL PROTECTED]| --- ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OpenIB Wiki pages updated
try --with-addr_trans-mod On Wed, 2007-01-17 at 09:41 -0800, Woodruff, Robert J wrote: > Vladimir wrote, > >Hi, > >The following links were added to > https://wiki.openfabrics.org/tiki-index.php: > > >OFED 1.2 HowTo > >HOWTO Build OFA user package > >HOWTO Build OFA kernel package > >HOWTO add userspace package to ofa_user > > > >Regards, > >Vladimir > > How do I make it build the rdma_cm and rdma_ucm, there appears to be no > configure > option in the ./configure script of the daily builds even though the > code is in > the core directory. ( I tried the 2/17/2007 kernel > daily build). > > woody > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] madeye
It's not well integrated into install.sh, you have to run: OPENIB_PARAMS="--with-madeye-mod" ./install.sh Scott Weitzenkamp SQA and Release Manager Server Virtualization Business Unit Cisco Systems > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Raleigh F Rinehart > Sent: Wednesday, January 17, 2007 9:48 AM > To: openib-general@openib.org > Subject: [openib-general] madeye > > I'm trying to use madeye in OFED 1.1 Release to do some > debugging but it > does not seem to be present. I cracked open src tarball and all the > right bits seem to be there (Kconfig, makefile, src) but it > doesn't seem > to get built and installed as part of the normal installation > procedure > (running install.sh). Has anyone had any success at building, > installing and using madeye in a release version of OFED? > > thanks, > -raleigh > > > cat /usr/local/ofed/BUILD_ID > OFED-1.1 > > openib-1.1 (REV=9905) > # User space > https://openib.org/svn/gen2/branches/1.1/src/userspace > Git: > ref: refs/heads/ofed_1_1 > commit a083ec1174cb4b5a5052ef5de9a8175df82e864a > > # MPI > mpi_osu-0.9.7-mlx2.2.0.tgz > openmpi-1.1.1-1.src.rpm > mpitests-2.0-0.src.rpm > > uname -a > Linux merrill2 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 > x86_64 x86_64 x86_64 GNU/Linux > > cat /etc/SuSE-release > SUSE Linux Enterprise Server 10 (x86_64) > VERSION = 10 > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
> +1 used only for unicast > +2 used only for multicast > +3 used for both unicast and multicast If you view this as the use case for one side only, we also have option 3 communicating with options 1 and 2. I would list these as: +4 unicast QP to unicast and multicast QP +5 multicast QP to unicast and multicast QP Today, all of these work. What you're wanting to add is the ability to communicate with an ipoib multicast group. I'd like to do this without breaking any of the existing communications, or treat ipoib separately for security reasons. > To make things simple, the solution i suggest is that that the RDMA CM > would --not-- do this modify QP/QKEY (that is would set the 0x12345678 > qkey on the modify qp to init) and rather leave it to the RDMA CM > consumer --if-- they wish to do so. However it will use the ipv4 > broadcast group qkey for doing mcast joins and report this qkey to the > user in the ud param of the event. We need to be able to handle options 4 and 5 as well. > this (what qkey is assigned to the ipv4 broadcast group by different > SAs) is orthogonal to the discussion we do here. This depends on whether verbs allows, or if it should allow, a user to specify a controlled qkey when configuring their QP. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] nightly osm_sim report 2007-01-15:normal completion
Hi Eitan, On Mon, 2007-01-15 at 00:17, Eitan Zahavi wrote: > OSM Simulation Regression Summary > OpenSM rev = Sat_Jan_13_09:43:14_2007 1f8015 > ibutils rev = Wed_Jan_3_11:42:12_2007 913448 > Total=410 Pass=409 Fail=1 > > Pass: > 30 Stability IS1-16.topo > 30 Pkey IS1-16.topo > 30 OsmTest IS1-16.topo > 30 OsmStress IS1-16.topo > 30 Multicast IS1-16.topo > 30 LidMgr IS1-16.topo > 10 Stability IS3-loop.topo > 10 Stability IS3-128.topo > 10 Pkey IS3-128.topo > 10 OsmTest IS3-loop.topo > 10 OsmTest IS3-128.topo > 10 Multicast IS3-loop.topo > 10 Multicast IS3-128.topo > 10 LidMgr IS3-128.topo > 10 FatTree part-4-ary-3-tree.topo > 10 FatTree merge-roots-reorder-4-ary-2-tree.topo > 10 FatTree merge-roots-4-ary-2-tree.topo > 10 FatTree merge-root-4-ary-3-tree.topo > 10 FatTree merge-root-12-ary-2-tree.topo > 10 FatTree merge-2-ary-4-tree.topo > 10 FatTree half-4-ary-3-tree.topo > 10 FatTree blend-4-ary-2-tree.topo > 10 FatTree 4-ary-4-tree.topo > 10 FatTree 4-ary-3-tree.topo > 10 FatTree 32nodes-3lvl-is1.topo > 10 FatTree 2-ary-4-tree.topo > 10 FatTree 12-node-spaced.topo > 10 FatTree 12-ary-2-tree.topo > 9 OsmStress IS3-128.topo > > Failures: > 1 OsmStress IS3-128.topo Any idea on this failure from a couple of days ago ? Will the other previous failures still be investigated at some point ? -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] madeye
I'm trying to use madeye in OFED 1.1 Release to do some debugging but it does not seem to be present. I cracked open src tarball and all the right bits seem to be there (Kconfig, makefile, src) but it doesn't seem to get built and installed as part of the normal installation procedure (running install.sh). Has anyone had any success at building, installing and using madeye in a release version of OFED? thanks, -raleigh cat /usr/local/ofed/BUILD_ID OFED-1.1 openib-1.1 (REV=9905) # User space https://openib.org/svn/gen2/branches/1.1/src/userspace Git: ref: refs/heads/ofed_1_1 commit a083ec1174cb4b5a5052ef5de9a8175df82e864a # MPI mpi_osu-0.9.7-mlx2.2.0.tgz openmpi-1.1.1-1.src.rpm mpitests-2.0-0.src.rpm uname -a Linux merrill2 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux cat /etc/SuSE-release SUSE Linux Enterprise Server 10 (x86_64) VERSION = 10 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OpenIB Wiki pages updated
Vladimir wrote, >Hi, >The following links were added to https://wiki.openfabrics.org/tiki-index.php: >OFED 1.2 HowTo >HOWTO Build OFA user package >HOWTO Build OFA kernel package >HOWTO add userspace package to ofa_user >Regards, >Vladimir How do I make it build the rdma_cm and rdma_ucm, there appears to be no configure option in the ./configure script of the daily builds even though the code is in the core directory. ( I tried the 2/17/2007 kernel daily build). woody ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH RFC 00/21] ofed_1_2 - Chelsio Backport to SLES9SP3
> BTW, Steve, I wouldn't start working on backports from SLES9. > I'd start with 2.6.19 and go back to 2.6.11 over kernel.org versions, > just making sure they build (we have this build environment on > openfabrics.org, > or its easy to check all versions out from kernel.org git). > In this way you get incrementtall a host of data on what is and what isn't in > which kernel version. > > Then adding support for a distro is just a matter of finding a closest > kernel.org kernel and mostly removing stuff that distro backported from newer > kernels. > Michael, Is there something magic about stopping at 2.6.11? ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] IB/ipoib_cm: reduce MTU on connected->datagram mode change
UD mode requires MTU <= broadcast group MTU, make sure MTU is valid when switching back from connected mode. Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]> --- Incremental patch on top of the IPoIB CM. Pls apply in for-mm. diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c index bb6a9b1..43500fd 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c @@ -1127,6 +1127,7 @@ static ssize_t set_mode(struct class_device *cdev, if (!strcmp(buf, "datagram\n")) { clear_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags); + dev->mtu = min(priv->mcast_mtu, dev->mtu); ipoib_flush_paths(dev); return count; } -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] OpenIB Wiki pages updated
Hi, The following links were added to https://wiki.openfabrics.org/tiki-index.php: OFED 1.2 HowTo HOWTO Build OFA user package HOWTO Build OFA kernel package HOWTO add userspace package to ofa_user Regards, Vladimir ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH 6/6] osm: Compiling new QoS parser files
Hi Hal Patch for compiling new QoS parser files. Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]> --- osm/include/Makefile.am |2 ++ osm/opensm/Makefile.am | 16 +++- osm/opensm/configure.in |4 3 files changed, 21 insertions(+), 1 deletions(-) diff --git a/osm/include/Makefile.am b/osm/include/Makefile.am index d6bdd84..62db6c2 100644 --- a/osm/include/Makefile.am +++ b/osm/include/Makefile.am @@ -118,6 +118,8 @@ EXTRA_DIST = \ $(srcdir)/opensm/osm_drop_mgr.h \ $(srcdir)/opensm/osm_port_info_rcv.h \ $(srcdir)/opensm/osm_state_mgr_ctrl.h \ + $(srcdir)/opensm/osm_qos_parser.h \ + $(srcdir)/opensm/osm_qos_parser_y.h \ $(srcdir)/complib/cl_thread_osd.h \ $(srcdir)/complib/cl_packon.h \ $(srcdir)/complib/cl_atomic_osd.h \ diff --git a/osm/opensm/Makefile.am b/osm/opensm/Makefile.am index dd6dbae..7fff9d7 100644 --- a/osm/opensm/Makefile.am +++ b/osm/opensm/Makefile.am @@ -71,7 +71,21 @@ opensm_SOURCES = main.c osm_console.c os osm_ucast_mgr.c osm_ucast_updn.c \ osm_ucast_file.c osm_ucast_ftree.c \ osm_vl15intf.c osm_vl_arb_rcv.c \ -osm_vl_arb_rcv_ctrl.c st.c +osm_vl_arb_rcv_ctrl.c st.c \ +osm_qos_parser_y.c osm_qos_parser_l.c + +osm_qos_parser_y.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/osm_qos_parser.y + $(YACC) -y -d $(srcdir)/osm_qos_parser.y + mv y.tab.c osm_qos_parser_y.c + mv y.tab.h osm_qos_parser_y.h + cp -f osm_qos_parser_y.c $(srcdir)/ + cp -f osm_qos_parser_y.h $(srcdir)/../include/opensm/ + +osm_qos_parser_l.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/osm_qos_parser.l + $(LEX) $(srcdir)/osm_qos_parser.l + mv lex.yy.c osm_qos_parser_l.c + cp -f osm_qos_parser_l.c $(srcdir)/ + if OSMV_OPENIB opensm_CFLAGS = -Wall $(OSMV_CFLAGS) -fno-strict-aliasing -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP $(DBGFLAGS) -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 opensm_CXXFLAGS = -Wall $(OSMV_CFLAGS) -DVENDOR_RMPP_SUPPORT -DDUAL_SIDED_RMPP $(DBGFLAGS) -D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1 diff --git a/osm/opensm/configure.in b/osm/opensm/configure.in index cecf932..496e806 100644 --- a/osm/opensm/configure.in +++ b/osm/opensm/configure.in @@ -14,6 +14,8 @@ if test -z $opensm_api_version; then fi AC_SUBST(opensm_api_version) +AM_MAINTAINER_MODE + dnl Checks for programs AC_PROG_CXX AC_PROG_CC @@ -22,6 +24,8 @@ AC_PROG_INSTALL AC_PROG_LN_S AC_PROG_MAKE_SET AC_PROG_LIBTOOL +AM_PROG_LEX +AC_PROG_YACC dnl Checks for libraries -- 1.4.4.1.GIT ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH 5/6] osm: QoS parser header file that defines parse tree data structures
Hi Hal This patch is a QoS parser header file that defines parse tree data structures. Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]> --- osm/include/opensm/osm_qos_parser.h | 172 +++ 1 files changed, 172 insertions(+), 0 deletions(-) diff --git a/osm/include/opensm/osm_qos_parser.h b/osm/include/opensm/osm_qos_parser.h new file mode 100644 index 000..4e27c8c --- /dev/null +++ b/osm/include/opensm/osm_qos_parser.h @@ -0,0 +1,172 @@ +/* + * Copyright (c) 2004-2006 Voltaire, Inc. All rights reserved. + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved. + * Copyright (c) 1996-2003 Intel Corporation. All rights reserved. + * + * This software is available to you under a choice of one of two + * licenses. You may choose to be licensed under the terms of the GNU + * General Public License (GPL) Version 2, available from the file + * COPYING in the main directory of this source tree, or the + * OpenIB.org BSD license below: + * + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above + *copyright notice, this list of conditions and the following + *disclaimer. + * + * - Redistributions in binary form must reproduce the above + *copyright notice, this list of conditions and the following + *disclaimer in the documentation and/or other materials + *provided with the distribution. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + * + */ + +/* + * Abstract: + *Declaration of OSM QoS parser. + * + * Environment: + *Linux User Mode + * + * Author: + *Yevgeny Kliteynik, Mellanox + */ + +#ifndef OSM_QOS_PARSER_H +#define OSM_QOS_PARSER_H + +#include +#include +#include +#include +#include +#include +#include +#include + +#define YYSTYPE char * + +#define OSM_QOS_NODE_TYPE_CA "CA" +#define OSM_QOS_NODE_TYPE_SWITCH "SWITCH" +#define OSM_QOS_NODE_TYPE_ROUTER "ROUTER" + +typedef enum {UNDEF, ROUTER, CA, SWITCH} node_type_t; + +/***/ + +typedef struct osm_qos_string_vector_item_t_ { + cl_map_item_t map_item; + char * str; +} osm_qos_string_vector_item_t; + +typedef struct osm_qos_uint64_vector_item_t_ { + cl_map_item_t map_item; + uint64_tvalue; +} osm_qos_uint64_vector_item_t; + +typedef struct osm_qos_uint32_vector_item_t_ { + cl_map_item_t map_item; + uint32_tvalue; +} osm_qos_uint32_vector_item_t; + +typedef struct osm_qos_vlarb_hl_vector_item_t_ { + cl_map_item_t map_item; + uint32_tsl; + uint32_tcredits; +} osm_qos_vlarb_hl_vector_item_t; + +/***/ + +typedef struct osm_qos_port_group_t_ { + cl_map_item_tmap_item; + char * name; + char * use; + cl_ptr_vector_t port_guids; /* vector of uint64_t */ + cl_ptr_vector_t port_names; /* vector of string */ + cl_ptr_vector_t partitions; /* vector of string */ + cl_ptr_vector_t node_types; /* vector of uint8_t */ +} osm_qos_port_group_t; + +/***/ + +typedef struct osm_qos_sl2vl_scope_t_ { + cl_map_item_tmap_item; + cl_ptr_vector_t groups; /* vector of string */ + cl_ptr_vector_t from;/* vector of string */ + cl_ptr_vector_t to; /* vector of string */ + cl_ptr_vector_t across_from; /* vector of string */ + cl_ptr_vector_t across_to; /* vector of string */ + uint8_t sl2vl_table[16]; +} osm_qos_sl2vl_scope_t; + +/***/ + +typedef struct osm_qos_vlarb_scope_t_ { + cl_map_item_tmap_item; + cl_ptr_vector_t groups; /* vector of string */ + cl_ptr_vector_t across; /* vector of string */ + cl_ptr_vector_t vlarb_highs; /* vector of string */ + cl_ptr_vector_t vlarb_lows; /* vector of string */ + uint32_t vl_high_limit; +} osm_qos_vlarb_scope_t; + +/***/ + +typedef struct osm_qos_level_t_ { + cl_map_item_tmap_item; + char * use; + uint32_t sn; + uint32_t sl; + uint32_t mtu_limit; + uint32_t rate_limit; + uint32_t class; +} osm_qos_level_t; + +/***/ + +typedef struct osm_qos_match_
[openib-general] [PATCH 1/6] osm: QoS parser Lex file
Hi Hal. This patch is QoS parser Lex file Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]> --- osm/opensm/osm_qos_parser.l | 245 +++ 1 files changed, 245 insertions(+), 0 deletions(-) diff --git a/osm/opensm/osm_qos_parser.l b/osm/opensm/osm_qos_parser.l new file mode 100644 index 000..73b2a29 --- /dev/null +++ b/osm/opensm/osm_qos_parser.l @@ -0,0 +1,245 @@ +%{ +/* + * Copyright (c) 2004-2006 Voltaire, Inc. All rights reserved. + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved. + * Copyright (c) 1996-2003 Intel Corporation. All rights reserved. + * + * This software is available to you under a choice of one of two + * licenses. You may choose to be licensed under the terms of the GNU + * General Public License (GPL) Version 2, available from the file + * COPYING in the main directory of this source tree, or the + * OpenIB.org BSD license below: + * + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above + *copyright notice, this list of conditions and the following + *disclaimer. + * + * - Redistributions in binary form must reproduce the above + *copyright notice, this list of conditions and the following + *disclaimer in the documentation and/or other materials + *provided with the distribution. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + * + */ + +/* + * Abstract: + *Lexer of OSM QoS parser. + * + * Environment: + *Linux User Mode + * + * Author: + *Yevgeny Kliteynik, Mellanox + */ + +#include +#include + +#define SAVE_POS save_pos() +static void save_pos(); + +extern int column_num; +extern int line_num; +extern FILE * yyin; + +%} + +XML_VERSION_START <\? +XML_VERSION_END \?> +QOS_POLICY_START +QOS_POLICY_END<\/qos\-policy> +PORT_GROUPS_START +PORT_GROUPS_END <\/port\-groups> +PORT_GROUP_START +PORT_GROUP_END<\/port\-group> +NAME_START +NAME_END <\/name> +USE_START +USE_END <\/use> +PORT_GUID_START +PORT_GUID_END <\/port\-guid> +PORT_NAME_START +PORT_NAME_END <\/port\-name> +PARTITION_START +PARTITION_END <\/partition> +NODE_TYPE_START +NODE_TYPE_END <\/node\-type> +QOS_SETUP_START +QOS_SETUP_END <\/qos\-setup> +SL2VL_TABLES_START +SL2VL_TABLES_END <\/sl2vl\-tables> +SL2VL_SCOPE_START +SL2VL_SCOPE_END <\/sl2vl\-scope> +GROUP_START +GROUP_END <\/group> +FROM_START +FROM_END <\/from> +TO_START +TO_END<\/to> +SL2VL_TABLE_START +SL2VL_TABLE_END <\/sl2vl\-table> +ACROSS_START +ACROSS_END<\/across> +ACROSS_FROM_START +ACROSS_FROM_END <\/across\-from> +ACROSS_TO_START +ACROSS_TO_END <\/across\-to> +VLARB_TABLES_START +VLARB_TABLES_END <\/vlarb\-tables> +VLARB_SCOPE_START +VLARB_SCOPE_END <\/vlarb\-scope> +VLARB_HIGH_START +VLARB_HIGH_END<\/vlarb\-high> +VLARB_LOW_START +VLARB_LOW_END <\/vlarb\-low> +VLARB_HIGH_LIMIT_START +VLARB_HIGH_LIMIT_END <\/vl\-high\-limit> +QOS_LEVELS_START +QOS_LEVELS_END<\/qos\-levels> +QOS_LEVEL_START +QOS_LEVEL_END <\/qos\-level> +SN_START +SN_END<\/sn> +SL_START +SL_END<\/sl> +CLASS_START +CLASS_END <\/class> +MTU_LIMIT_START +MTU_LIMIT_END <\/mtu\-limit> +RATE_LIMIT_START +RATE_LIMIT_END<\/rate\-limit> +QOS_MATCH_RULES_START +QOS_MATCH_RULES_END <\/qos\-match\-rules> +QOS_MATCH_RULE_START +QOS_MATCH_RULE_END<\/qos\-match\-rule> +QOS_LEVEL_SN_START +QOS_LEVEL_SN_END <\/qos\-level\-sn> +SOURCE_START +SOURCE_END<\/source> +DESTINATION_START +DESTINATION_END <\/destination> +SERVICE_START +SERVICE_END <\/service> + +WHITE [
[openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Hal The following series of six patches implements QoS policy file parser: 1. QoS parser Lex file 2. QoS parser Lex-generated c file 3. QoS parser grammar (Yacc) file 4. QoS parser Yacc-generated grammar c and h file 5. QoS parser header file that defines parse tree data structures 6. Changes in makefiles and configure.in file for compiling QoS parser files -- Yevgeny Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]> ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
> Quoting Or Gerlitz <[EMAIL PROTECTED]>: > Subject: Re: [openfabrics-ewg] Minutes for January 15, 2007 teleconference > about OFED 1.2 development progress toward code freeze > > Tziporet Koren wrote: > > Or Gerlitz wrote: > >> Tziporet Koren wrote: > >> > >> > >> The bonding package would support: fresh (2.6.20) and some older > >> upstream kernels along with SLES10 and RH4 Ux (x=3 for sure) > >> > >> > > OK - please send us all the info once its ready > >>> General changes to the package: > >>> * Multicast - we wait for Voltaire and Sean to close all technical > >>> details - should be ready by the end of the week > >>> > >> > >> I have just sent Sean over the list a clarification email, if needed > >> we would be able to help doing the missing patches and i guess in a > >> combined effort this would be ready for the end of --next-- week > >> > >> > > Thanks - please work with MST & Vlad on integration > >> what about the host side QoS code? i did not see an newer RFC nor > >> patch other then the RFC that was sent many months ago. > > > We are going to update our low level driver (mthca) to support it. > > > Beside there should be a small change in CMA for this, and its specified > > in the RFC. > > I understand that the change involves letting the rdma cm know the SID > when the consumer calls --rdma_resolve_route-- where today it get to > know the SID when the consumer calls --rdma_connect-- . So this is not > an internal RDMA CM change but rather also changes the API. > > Same for SRP as the api of ib_sa_path_rec_get (that is the structure it > gets as input) changes, the SRP code also changes. > > Any, can you send the mthca and rdmacm/rdmacm-consumers changes as > RFC/PATCH over the list before the actual code freeze??? I didn't start on this code yet, but it does not look like a huge project, I hope to post code by next week. To avoid major disruptions all over the stack, my preference for OFED 1.2 would be to add new API calls and a module option (off by default) for cma/srp to use them. > As for the QoS RFC > (http://openib.org/pipermail/openib-general/2006-May/022331.html) sent > by Eitan, one design issue I see there is how to deal with IB ULPs which > do --not-- have a well known SID. So they call ib_cm_listen with > IB_CM_ASSIGN_SERVICE_ID and get from the CM a service id to use, then > they might do some out of band exchange of this SID before starting > their connection establishment. > > from include/rdma/ib_cm.h > > > * @service_id: Service identifier matched against incoming connection > > * and service ID resolution requests. The service ID should be specified > > * network-byte order. If set to IB_CM_ASSIGN_SERVICE_ID, the CM will > > * assign a service ID to the caller. > > Typically this happens with MPI up to the extent that different ranks > within the same job may get a different SID. One solution i was thinking > of is to > > +1 define --range-- (eg big enough to serve 1024 CM consumers) per ULP > +2 change the CM to support allocating SID in a range > +3 change the ULPs which use IB_CM_ASSIGN_SERVICE_ID to ask SID in the > relevant range > +4 change the QoS manager at the SM side to support ranges For OFED 1.2, I only planned to implement this for SDP and SRP. I do not expect all this to be mergeable in 2.6.21 time frame, so maybe that's enough. So I think I'll opt for an easier +5 don't set SID in path record query for userspace apps -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OFED ipoib_8111_to_2_6_16.patch
> However, since understanding this patch in detail is important to a peer > member individual/company of the community (myself/Voltaire)fo/openib-general I really would like to help. What is it that you want to know? Here's an explanation from an older mail. Does this help? Work around for neighbour destructor issue for kernels < 2.6.17: keep a global list of all ipoib neighbours. Use it in destructor to 1. Verify that this neighbour belongs to an ipoib device 2. Check that the neighbour is the last one to use the destructor, if so reset the destructor pointer -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
> > Maybe a machanism should be in place to control access to this separately > > from regular rdma cm for RC QPs? > > not following you here, how does qkey relates to RC QPs ? Currently you can block userspace from creating QPs by unloading uverbs module. Maybe we should make it possible to block creating UD QPs from userspace as a separate security measure. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OFED ipoib_8111_to_2_6_16.patch
Or Gerlitz wrote: > Michael S. Tsirkin wrote: git log -Sneigh_destructor -- include/net/neighbour.h >>> also, having that at (my) hand does not remove the need that you will >>> set a changelog/signature for the OFED ipoib related backport patch. >> Feel free to add that. > Unless i miss something, we want all OFED kernel patches to meet > **basic** kernel working conversions, specifically that for each patch > there is a change log and an owner. OK, I realize now that in OFED 1.1 out of 438 .patch files under kernel_patches only 103 of them have Signed-Off-by line and assuming this maps 1:1 to the files that have change log, i am not asking you to write now 335 change-logs/signed-off-by section. However, since understanding this patch in detail is important to a peer member individual/company of the community (myself/Voltaire) and you being this patch owner and also having the OFED kernel patches maintainer chair, it makes sense that per our request you will put 5 minutes of your time to write a change log. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
Michael S. Tsirkin wrote: >> Quoting Sean Hefty <[EMAIL PROTECTED]>: >> Subject: Re: multicast code/merge status >> >>> sure, it can use the rdmacm qkey (0x1234567 etc) when it creates the QP >>> and later --if-- the user joins a multicast group modify the qp state >>> with the group qkey and report it in the cma event such that the >>> consumer of the rdmacm would set this into his IB UD TX WR >> Changing the qkey would break its existing UD communication. >> >>> Bottom line, Looking in the IB SPEC and IPoIB RFC i did not see >>> mentioning of privileged QKEY. >> From RFC 4391 (ipoib RFC), 4.1: >> >> 2. Q_Key >> >>It is RECOMMENDED that a controlled Q_Key be used with the >>high-order bit set. This is to prevent non-privileged >>software from fabricating and sending out bogus IP datagrams. > > BTW, should we be worried that proposed extension (passing qkey in rdma cm > param > list) seems to expose this qkey to non-privileged software? As was said over related threads here and elsewhere, multicast has its in nature non safeties and having IB implement broadcast over multicast adds more in safety to the party. Specifically, as Roland has commented, a user can attach his user space UD QP to the MGID of the ipv4 broadcast(if ipoib is running on this node it will join the group) and start making this IP subnet go crazy. We only want interop with IPoIB and we don't need to join/attach the ipv4 broadcast group just have an option for the rdmacm to use its qkey for joins and later either the rdmacm or the consumer will also set this qkey into the QP and the UD TX WR > Maybe a machanism should be in place to control access to this separately > from regular rdma cm for RC QPs? not following you here, how does qkey relates to RC QPs ? Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
Tziporet Koren wrote: > Or Gerlitz wrote: >> Tziporet Koren wrote: >> >> >> The bonding package would support: fresh (2.6.20) and some older >> upstream kernels along with SLES10 and RH4 Ux (x=3 for sure) >> >> > OK - please send us all the info once its ready >>> General changes to the package: >>> * Multicast - we wait for Voltaire and Sean to close all technical >>> details - should be ready by the end of the week >>> >> >> I have just sent Sean over the list a clarification email, if needed >> we would be able to help doing the missing patches and i guess in a >> combined effort this would be ready for the end of --next-- week >> >> > Thanks - please work with MST & Vlad on integration >> what about the host side QoS code? i did not see an newer RFC nor >> patch other then the RFC that was sent many months ago. > We are going to update our low level driver (mthca) to support it. > Beside there should be a small change in CMA for this, and its specified > in the RFC. I understand that the change involves letting the rdma cm know the SID when the consumer calls --rdma_resolve_route-- where today it get to know the SID when the consumer calls --rdma_connect-- . So this is not an internal RDMA CM change but rather also changes the API. Same for SRP as the api of ib_sa_path_rec_get (that is the structure it gets as input) changes, the SRP code also changes. Any, can you send the mthca and rdmacm/rdmacm-consumers changes as RFC/PATCH over the list before the actual code freeze??? As for the QoS RFC (http://openib.org/pipermail/openib-general/2006-May/022331.html) sent by Eitan, one design issue I see there is how to deal with IB ULPs which do --not-- have a well known SID. So they call ib_cm_listen with IB_CM_ASSIGN_SERVICE_ID and get from the CM a service id to use, then they might do some out of band exchange of this SID before starting their connection establishment. from include/rdma/ib_cm.h > * @service_id: Service identifier matched against incoming connection > * and service ID resolution requests. The service ID should be specified > * network-byte order. If set to IB_CM_ASSIGN_SERVICE_ID, the CM will > * assign a service ID to the caller. Typically this happens with MPI up to the extent that different ranks within the same job may get a different SID. One solution i was thinking of is to +1 define --range-- (eg big enough to serve 1024 CM consumers) per ULP +2 change the CM to support allocating SID in a range +3 change the ULPs which use IB_CM_ASSIGN_SERVICE_ID to ask SID in the relevant range +4 change the QoS manager at the SM side to support ranges Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] History change in srptools.git
Hi I changed the history in srptools.git (Some e-mail addresses errors) The change is only on the log information. The files was not changed. The change: version 19c761889b9bd86abc027a13c1c6d0a96607fe79 become version 2088b76f62cd0e94d2c8415a6a328dc818d200f1 If you are working on it you will need to perform rebase. Sorry for any inconvenient. Thanks Ishai ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
> Quoting Sean Hefty <[EMAIL PROTECTED]>: > Subject: Re: multicast code/merge status > > > sure, it can use the rdmacm qkey (0x1234567 etc) when it creates the QP > > and later --if-- the user joins a multicast group modify the qp state > > with the group qkey and report it in the cma event such that the > > consumer of the rdmacm would set this into his IB UD TX WR > > Changing the qkey would break its existing UD communication. > > > Bottom line, Looking in the IB SPEC and IPoIB RFC i did not see > > mentioning of privileged QKEY. > > From RFC 4391 (ipoib RFC), 4.1: > > 2. Q_Key > >It is RECOMMENDED that a controlled Q_Key be used with the >high-order bit set. This is to prevent non-privileged >software from fabricating and sending out bogus IP datagrams. BTW, should we be worried that proposed extension (passing qkey in rdma cm param list) seems to expose this qkey to non-privileged software? Maybe a machanism should be in place to control access to this separately from regular rdma cm for RC QPs? -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] multicast code/merge status
Sean Hefty wrote: >> sure, it can use the rdmacm qkey (0x1234567 etc) when it creates the >> QP and later --if-- the user joins a multicast group modify the qp >> state with the group qkey and report it in the cma event such that the >> consumer of the rdmacm would set this into his IB UD TX WR > Changing the qkey would break its existing UD communication. OK, so we have three use cases here for a UD QP +1 used only for unicast +2 used only for multicast +3 used for both unicast and multicast and my suggestion (default qkey, when join is completed do qp modify with the group qkey) would work fine for use cases 1 - since the user never joins to anything and 2 - same as it works in ipoib so we are left with use case 3. To make things simple, the solution i suggest is that that the RDMA CM would --not-- do this modify QP/QKEY (that is would set the 0x12345678 qkey on the modify qp to init) and rather leave it to the RDMA CM consumer --if-- they wish to do so. However it will use the ipv4 broadcast group qkey for doing mcast joins and report this qkey to the user in the ud param of the event. So users that don't care about their qkey would never bother to do this modify qp and users who do care would do it and have to take caution if their QP is of type 3 (both unicast and mcast). If you don't like this direction, your idea from below to have two option for group type - rdmacm or ipoib and have the consumer specify it, so for group type ipoib you will use the ipv4 brd qkey for both join and modify qp and for group type rdmacm you would just use the rdmacm qkey and do no modify qp - this is fine for us as well. >> Bottom line, Looking in the IB SPEC and IPoIB RFC i did not see >> mentioning of privileged QKEY. > > From RFC 4391 (ipoib RFC), 4.1: > > 2. Q_Key > > It is RECOMMENDED that a controlled Q_Key be used with the > high-order bit set. This is to prevent non-privileged > software from fabricating and sending out bogus IP datagrams. > > I don't know what qkey is actually assigned, however. this (what qkey is assigned to the ipv4 broadcast group by different SAs) is orthogonal to the discussion we do here. > I have some path forward related tasks that I would like to complete > before starting on this. I hope to finish that before the end of this > week. I don't want to rush on the multicast support and miss > something. For the rdma cm, we may need to let the user set some > options when joining a multicast group. Maybe something like: join type > (send-only or send-receive), group type (ipoib or rdma defined), etc. As I see it, the group type (or having no types and being always interoperable with ipoib as i suggest above) seems easy to add to the current implementation and would put it in acceptable state for upstream pushing to 2.6.21 and inclusion in OFED 1.2 . As for the join type, as i told you before, I think it should --not-- delay the upstream nor the ofed 1.2 push - if you have the time add this to the user/kernel ABI and have ucma kernel return -EINVAL if someone attempts to to send-only join. And if you don't have the time for that, it can be added later. Actually, as you can see in the ipoib code, it never does a send-only-non-member join, so my take here is that till the ipoib issue is resolved there is no reason to have this complexity in the rdmacm. > I do plan on requesting that the core multicast changes to ib_sa and > ib_ipoib be pulled into 2.6.21. This is great news but again I think the "nobody perfect" rule applies well here, the current rdmacm multicast support (which the little fixes we discuss over this thread) can be pushed to 2.6.21 and be enhanced later. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [srptools] [PATCH] Added checks to memory allocation failure when using asprintf
Applied, Thanks Ishai ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [srptools] [PATCH] style fix in asprintf result check
Applied, Thanks Ishai ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [libibverbs/examples] [PATCH] Added resource cleaning before end of pingpong tests + ack to CQ events
Added resource cleaning before end of pingpong tests + ack to CQ events. Signed-off-by: Dotan Barak <[EMAIL PROTECTED]> --- Index: gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c === --- gen2_devel_user.orig/src/userspace/libibverbs/examples/rc_pingpong.c 2007-01-17 10:58:02.0 +0200 +++ gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c 2007-01-17 11:09:59.0 +0200 @@ -322,7 +322,7 @@ static struct pingpong_context *pp_init_ ctx->mr = ibv_reg_mr(ctx->pd, ctx->buf, size, IBV_ACCESS_LOCAL_WRITE); if (!ctx->mr) { - fprintf(stderr, "Couldn't allocate MR\n"); + fprintf(stderr, "Couldn't register MR\n"); return NULL; } @@ -374,6 +374,46 @@ static struct pingpong_context *pp_init_ return ctx; } +int pp_close_ctx(struct pingpong_context *ctx) +{ + if (ibv_destroy_qp(ctx->qp)) { + fprintf(stderr, "Couldn't destroy QP\n"); + return 1; + } + + if (ibv_destroy_cq(ctx->cq)) { + fprintf(stderr, "Couldn't destroy CQ\n"); + return 1; + } + + if (ibv_dereg_mr(ctx->mr)) { + fprintf(stderr, "Couldn't deregister MR\n"); + return 1; + } + + if (ibv_dealloc_pd(ctx->pd)) { + fprintf(stderr, "Couldn't deallocate PD\n"); + return 1; + } + + if (ctx->channel) { + if (ibv_destroy_comp_channel(ctx->channel)) { + fprintf(stderr, "Couldn't destroy completion channel\n"); + return 1; + } + } + + if (ibv_close_device(ctx->context)) { + fprintf(stderr, "Couldn't release context\n"); + return 1; + } + + free(ctx->buf); + free(ctx); + + return 0; +} + static int pp_post_recv(struct pingpong_context *ctx, int n) { struct ibv_sge list = { @@ -451,6 +491,7 @@ int main(int argc, char *argv[]) int use_event = 0; int routs; int rcnt, scnt; + int num_of_events = 0; srand48(getpid() * time(NULL)); @@ -622,6 +663,8 @@ int main(int argc, char *argv[]) return 1; } + ++num_of_events; + if (ev_cq != ctx->cq) { fprintf(stderr, "CQ event for unknown CQ %p\n", ev_cq); return 1; @@ -706,5 +749,13 @@ int main(int argc, char *argv[]) iters, usec / 100., usec / iters); } + ibv_ack_cq_events(ctx->cq, num_of_events); + + if (pp_close_ctx(ctx)) + return 1; + + ibv_free_device_list(dev_list); + free(rem_dest); + return 0; } Index: gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c === --- gen2_devel_user.orig/src/userspace/libibverbs/examples/srq_pingpong.c 2007-01-17 10:58:02.0 +0200 +++ gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c 2007-01-17 11:10:31.0 +0200 @@ -358,7 +358,7 @@ static struct pingpong_context *pp_init_ ctx->mr = ibv_reg_mr(ctx->pd, ctx->buf, size, IBV_ACCESS_LOCAL_WRITE); if (!ctx->mr) { - fprintf(stderr, "Couldn't allocate MR\n"); + fprintf(stderr, "Couldn't register MR\n"); return NULL; } @@ -424,6 +424,55 @@ static struct pingpong_context *pp_init_ return ctx; } +int pp_close_ctx(struct pingpong_context *ctx, int num_qp) +{ + int i; + + for (i = 0; i < num_qp; ++i) { + if (ibv_destroy_qp(ctx->qp[i])) { + fprintf(stderr, "Couldn't destroy QP[%d]\n", i); + return 1; + } + } + + if (ibv_destroy_srq(ctx->srq)) { + fprintf(stderr, "Couldn't destroy SRQ\n"); + return 1; + } + + if (ibv_destroy_cq(ctx->cq)) { + fprintf(stderr, "Couldn't destroy CQ\n"); + return 1; + } + + if (ibv_dereg_mr(ctx->mr)) { + fprintf(stderr, "Couldn't deregister MR\n"); + return 1; + } + + if (ibv_dealloc_pd(ctx->pd)) { + fprintf(stderr, "Couldn't deallocate PD\n"); + return 1; + } + + if (ctx->channel) { + if (ibv_destroy_comp_channel(ctx->channel)) { + fprintf(stderr, "Couldn't destroy completion channel\n"); + return 1; + } + } + + if (ibv_close_device(ctx->context)) { + fprintf(stderr, "Couldn't release context\n"); + retur
[openib-general] [libibverbs/examples] [PATCH] Added checks to memory allocation failure when using asprintf in pingpong tests
Added checks to memory allocation failure when using asprintf in pingpong tests. Signed-off-by: Dotan Barak <[EMAIL PROTECTED]> --- Index: gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c === --- gen2_devel_user.orig/src/userspace/libibverbs/examples/rc_pingpong.c 2007-01-15 17:02:23.0 +0200 +++ gen2_devel_user/src/userspace/libibverbs/examples/rc_pingpong.c 2007-01-16 09:56:52.0 +0200 @@ -139,7 +139,9 @@ static struct pingpong_dest *pp_client_e int sockfd = -1; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(servername, service, &hints, &res); if (n < 0) { @@ -205,7 +207,9 @@ static struct pingpong_dest *pp_server_e int sockfd = -1, connfd; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(NULL, service, &hints, &res); if (n < 0) { Index: gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c === --- gen2_devel_user.orig/src/userspace/libibverbs/examples/srq_pingpong.c 2007-01-15 17:02:23.0 +0200 +++ gen2_devel_user/src/userspace/libibverbs/examples/srq_pingpong.c 2007-01-16 09:57:25.0 +0200 @@ -150,7 +150,9 @@ static struct pingpong_dest *pp_client_e int sockfd = -1; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(servername, service, &hints, &res); if (n < 0) { @@ -229,7 +231,9 @@ static struct pingpong_dest *pp_server_e int sockfd = -1, connfd; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(NULL, service, &hints, &res); if (n < 0) { Index: gen2_devel_user/src/userspace/libibverbs/examples/uc_pingpong.c === --- gen2_devel_user.orig/src/userspace/libibverbs/examples/uc_pingpong.c 2007-01-15 17:02:23.0 +0200 +++ gen2_devel_user/src/userspace/libibverbs/examples/uc_pingpong.c 2007-01-16 09:57:54.0 +0200 @@ -127,7 +127,9 @@ static struct pingpong_dest *pp_client_e int sockfd = -1; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(servername, service, &hints, &res); if (n < 0) { @@ -193,7 +195,9 @@ static struct pingpong_dest *pp_server_e int sockfd = -1, connfd; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(NULL, service, &hints, &res); if (n < 0) { Index: gen2_devel_user/src/userspace/libibverbs/examples/ud_pingpong.c === --- gen2_devel_user.orig/src/userspace/libibverbs/examples/ud_pingpong.c 2007-01-15 17:02:23.0 +0200 +++ gen2_devel_user/src/userspace/libibverbs/examples/ud_pingpong.c 2007-01-16 09:58:22.0 +0200 @@ -128,7 +128,9 @@ static struct pingpong_dest *pp_client_e int sockfd = -1; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(servername, service, &hints, &res); if (n < 0) { @@ -194,7 +196,9 @@ static struct pingpong_dest *pp_server_e int sockfd = -1, connfd; struct pingpong_dest *rem_dest = NULL; - asprintf(&service, "%d", port); + if (asprintf(&service, "%d", port) < 0) + return NULL; + n = getaddrinfo(NULL, service, &hints, &res); if (n < 0) { ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [libibverbs/examples] pingpong tests cleanup (resource destroy + ack events + asprintf failure check)
Roland Dreier wrote: > Looks pretty good, but could you please: > > - split off the asprintf() checks into a separate patch ("one idea >per patch"). > - change the code so it keeps a count of cq events and then just >does one ibv_ack_cq_events(cq, num_cq_events) at the end. If >people are going to use this code as an example, then we should >avoid expensive calls to ibv_ack_cq_events() (which has to do a >pthread_mutex_lock()/unlock() and a pthread_cond_signal()) in the >main data-moving flow. > > thanks... > - i wanted to give one patch with all of the fixes, but separate patches are fine by me (i will keep that in mind). - i will change the code according to this tip (and add it to the man pages of this verb) later on i will send the 2 patches. thanks Dotan ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Reminder: OFED 1.2
Jeff Squyres wrote: > FWIW, having git's for the MPI implementations was asked for on the > call yesterday (by Tziporet, IIRC?). The rationale, as I understood > it, was threefold: > > 1. Putting the MPI release in git provides a level of OFED-specific > history and version control. This was explicitly stated on the call > yesterday. > > 2. MPI's have concrete "releases" to OFED just like all other ULP's, > especially if there is any OFED-specific packaging involved in the > MPI's release. This was not stated on the call, but it makes sense > to me. > > 3. Putting everything in git makes it nicely uniform for OFED to be > assembled. This was not stated on the call, and I'm sure it's not a > requirement, but it is a little nice to be uniform when assembling > OFED (my $0.02). > > 4. We used to put the MPI releases in SVN (tarball or SRPM) for prior > OFED release processes, so putting them in a git seems to parallel > that procedure. > > I don't really care one way or another; this was just my > understanding of why it was requested. > > > Hi, Jeff is correct - I requested this from the reasons above. Tziporet ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
Or Gerlitz wrote: > Tziporet Koren wrote: > > > > The bonding package would support: fresh (2.6.20) and some older > upstream kernels along with SLES10 and RH4 Ux (x=3 for sure) > > OK - please send us all the info once its ready >> General changes to the package: >> * Multicast - we wait for Voltaire and Sean to close all technical >> details - should be ready by the end of the week >> > > I have just sent Sean over the list a clarification email, if needed we > would be able to help doing the missing patches and i guess in a > combined effort this would be ready for the end of --next-- week > > Thanks - please work with MST & Vlad on integration > what about the host side QoS code? i did not see an newer RFC nor patch > other then the RFC that was sent many months ago. > > > We are going to update our low level driver (mthca) to support it. Beside there should be a small change in CMA for this, and its specified in the RFC. Tziporet ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
Roland Dreier wrote: > I believe I have a way to make libibverbs 1.1 binary-compatible with > applications (but not drivers) built against libibverbs 1.0. So it > will probably not be necessary to include libibverbs 1.0. > > - R. > > This is very good. When will we have this change (since libibverbs is very centric I prefer having it sooner than later) Thanks, Tziporet ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general