[ewg] Unique men's health shop
When your wife is angry with your bad potence. Dont try your luck in bed, ensure your potence with ANTIEDs. Here! fLacctdisk epexegesis fairbairns fBgetfsent extradites enforcment ewhereupon fBinternat excalbians extincting felicitous externname ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: [ofw] Developer's Workshop at SC'08
Woodruff, Robert J wrote: > Hi Guys, > > I have been asked by the OpenFabrics marketing working group to gauge > the possible interest in having a developer workshop during the > week of SC'08 in Austin. There are already plans to have BOFs at SC'08 > to provide customers with updates on the upcoming releases, i.e, OFED > 1.4 > and WinOF 2.0. > > The question is, do you think we need a developers workshop that week > as well > to perhaps plan future work, OFED 1.5, WinOF 2.1 etc. or do you think > a face-to-face meeting is not needed this fall and wait till next > spring at Sonoma > for the next face-to-face. > > Thoughts ? For the Windows Working Group, our bi-weekly teleconferences, and soon to be weekly RC meetings have the communications flowing reasonable well. We are still catching up to Linux w.r.t. functionality. A developers workshop the week of SC'08 would not be a high priority, although others may see benefits. Stan. > > woody > ___ > ofw mailing list > [EMAIL PROTECTED] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [ANNOUNCE] management tarballs release
On 13:53 Wed 09 Jul , Hal Rosenstock wrote: > > > > It is just *.ver file, *.map is symbol versioning - there were additions, > > no changes in existing functions API. > > Isn't that needed too when APIs are added ? I don't think. > Also, some existing > functions had minor parameter changes (like const being added). Yes, but it does not touch ABI and doesn't affect a linker. > > > > this will take effect in the next daily build. > > > > > > The tar balls just issued won't be reissued ? > > > > There were some commits after this already. > > Shouldn't there be a branch for this if that is an issue ? And then to do libibmad-1.2.1.1? Looks like an overkill for this particular case - 1.2.* is in development period and the issue is pretty minor - we will fix it in today's daily build and in the next tarball release. Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [ANNOUNCE] management tarballs release
On Wed, 2008-07-09 at 23:46 +0300, Sasha Khapyorsky wrote: > On 13:22 Wed 09 Jul , Hal Rosenstock wrote: > > > > Thanks. Is it just libibmad or was it also libibumad as well ? > > No API related changes were in libibumad. > > Is it > > just the *.ver file or also the version in the *.map file ? > > It is just *.ver file, *.map is symbol versioning - there were additions, > no changes in existing functions API. Isn't that needed too when APIs are added ? Also, some existing functions had minor parameter changes (like const being added). > > > this will take effect in the next daily build. > > > > The tar balls just issued won't be reissued ? > > There were some commits after this already. Shouldn't there be a branch for this if that is an issue ? -- Hal > Sasha > ___ > general mailing list > [EMAIL PROTECTED] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [ANNOUNCE] management tarballs release
On 13:22 Wed 09 Jul , Hal Rosenstock wrote: > > Thanks. Is it just libibmad or was it also libibumad as well ? No API related changes were in libibumad. > Is it > just the *.ver file or also the version in the *.map file ? It is just *.ver file, *.map is symbol versioning - there were additions, no changes in existing functions API. > > this will take effect in the next daily build. > > The tar balls just issued won't be reissued ? There were some commits after this already. Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [ofa-general] [ANNOUNCE] management tarballs release
On Wed, 2008-07-09 at 22:05 +0300, Sasha Khapyorsky wrote: > On 11:57 Wed 09 Jul , Hal Rosenstock wrote: > > > 891c907cf7fb56191c1cd4224608ef63 libibmad-1.2.1.tar.gz > > > > There have been API additions and changes in the libraries since last > > release. Although the tarball versions have changed, have the ones in > > the library map files changed ? Don't they need to be updated to reflect > > the API additions/changes ? > > Yes, I missed thiat (thought it was done with the API addition patch). I > will update the library version, Thanks. Is it just libibmad or was it also libibumad as well ? Is it just the *.ver file or also the version in the *.map file ? > this will take effect in the next daily build. The tar balls just issued won't be reissued ? -- Hal > Sasha > ___ > ewg mailing list > ewg@lists.openfabrics.org > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] [ANNOUNCE] management tarballs release
On 11:57 Wed 09 Jul , Hal Rosenstock wrote: > > 891c907cf7fb56191c1cd4224608ef63 libibmad-1.2.1.tar.gz > > There have been API additions and changes in the libraries since last > release. Although the tarball versions have changed, have the ones in > the library map files changed ? Don't they need to be updated to reflect > the API additions/changes ? Yes, I missed thiat (thought it was done with the API addition patch). I will update the library version, this will take effect in the next daily build. Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ofa-general] [ANNOUNCE] management tarballs release
Sasha, On Wed, 2008-07-09 at 08:03 +0300, Sasha Khapyorsky wrote: > Hi, > > There is a new release of the management (OpenSM and infiniband > diagnostics) tarballs available in: > > http://www.openfabrics.org/downloads/management/ > > md5sum: > > 59737e8ef106c3a37a3bab690397d973 libibcommon-1.1.1.tar.gz > 40d87f68e6259eb25e85f89d27b95f63 libibumad-1.2.1.tar.gz > 891c907cf7fb56191c1cd4224608ef63 libibmad-1.2.1.tar.gz There have been API additions and changes in the libraries since last release. Although the tarball versions have changed, have the ones in the library map files changed ? Don't they need to be updated to reflect the API additions/changes ? -- Hal > fd74b4456987ea78da8f1c2e7edf4f84 opensm-3.2.2.tar.gz > ff809b62b2f6cead7d33fb722d8638b6 infiniband-diags-1.4.1.tar.gz > > All component versions are from recent master branch. Full change log is > below. > > Sasha > > > Al Chu (7): > ids_guid_file manpage entry > add guid_routing_order_file option > rearch __osm_ucast_mgr_process_tbl() usage > implement guid_routing_order_file > fix true/false usage > Fix comment typo > Fix regenerate cache corner case. > > Hal Rosenstock (70): > OpenSM: Add QoS_management_in_OpenSM.txt to opensm/doc directory > OpenSM/doc/modular_routing.txt: Fix typo > OpenSM/doc/QoS_management_in_OpenSM.txt: Remove mention of OFED > management: Support separate SA and SM keys as clarified in IBA 1.2.1 > opensm/osm_sa_mcmember_record.c: Improve log message and some comments > relating to SNM > opensm/main.c: Minor change to long option for consolidate_ipv6_snm_req > OpenSM: Add another HP OUI to recognized vendor IDs > opensm/osm_subnet.c: Change comment for IPv6 SNM in options file > OpenSM/osm_sa_mcmember_record.c: Collapse all scopes when consolidating > IPv6 SNM > OpenSM release notes: Update to 3.1.11 > opensm/osm_lid_mgr.c: Eliminate some potential NULL pointer dereferences > opensm/osm_lin_fwd_tbl.c: Eliminate potential NULL pointer dereference > OpenSM/osm_sa_mcmember_record.c: Validate some more MGID bits for IPv6 > SNM > infiniband-diags/saquery.c: Update for change to osm_mad_pool_init API > opensm/osm_sa_mcmember_record.c: Minor logic change in __get_new_mlid > opensm/osm_ucast_ftree.c: Eliminate unnecessary check in > __osm_ftree_sw_tbl_element_create > opensm/osm_pkey.c: Eliminate potential NULL pointer dereference > opensm/osm_port.c: Eliminate potential NULL pointer dereferences > libibmad/fields.c: _set_field64 sets field in network rather than host > order > infiniband-diags/mcm_rereg_test.c: Handle error when guid file not found > infiniband-diags/ibsendtrap.c: Support CA and port num > OpenSM/osm_sa_mcmember_record.c: Comment reformatting > OpenSM: Remove some vestigial comments > infiniband-diags/saquery.c: In dump_results, use query_result rather > than query_svc_rec > opensm/libvendor/osm_vendor_ibumad_sa.c: Cosmetic changes > OpenSM/osm_sa_portinfo_record.c: Cosmetic comment change > OpenSM/osm_sa_mcmember_record.c: Cosmetic change to error log message > OpenSM/osm_sa_path_record.c: Add some information to some error log > messages > opensm/include/iba/ib_types.h: Fix comment > OpenSM/include/opensm: Fix some commentary typos > OpenSM/include/osm_port_profile.h: Fix some typos > OpenSM/libvendor/osm_vendor_ibumad_sa.c: Eliminate unneeded define > opensm/osm_lin_fwd_tbl.c: Minor change to __osm_lin_tbl_compute_obj_size > infiniband-diags/saquery.c: In print_multicast_group_records, only > query NodeRecords when needed > opensm/osm_sa_path_record.c: Break up some long OSM_LOG lines > opensm/osm_trap_rcv.c: Break up some long comment lines > opensm/osm_sa_mcmember_record.c: Breakup some long lines > opensm/osm_sa_mcmember_record.c: When consolidating SNM, need separate > group per PKey > opensm/man/opensm.8.in: Update consolidate_ipv6_snm_req description > opensm/osm_subnet.c: Fix typo > opensm/osm_sa_mcmember_record.c: Some error message improvements > opensm/include/opensm/osm_multicast.h: Cosmetic changes > opensm/osm_sa_mcmember_record.c: Cosmetic changes > opensm/osm_mcast_mgr.c: Cosmetic comment format change > opensm/osm_lid_mgr.c: Cosmetic formatting changes > opensm/include/osm_port.h: Eliminate some unneeded includes > opensm/include/osm_db.h: Fix some typos > opensm/include/osm_prefix_route.h: Support C++ inclusion > opensm/include/osm_mtree.h: Eliminate unneeded include > libibmad/rpc.c: Better error message in madrpc_init > opensm/osm_port.c: Cosmetic commentary changes > opensm/osm_switch: Cosmetic formatting changes > opensm/osm_subnet.h: Cosmetic formatting changes > opensm/osm_sa_mcmember_record.c: Fix some
[ewg] US $ 69.95 Viagra 100mg x 10 pills
50mg x 60 pills $119.95 http://medtexmedical.eu ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [Fwd: incorrect/obsolete link]
Hi Jeff. I guess the word "documentation" does not correspond to what the link points to. I think he was expecting man pages or something. -jeff Original Message Subject:incorrect/obsolete link Date: Wed, 9 Jul 2008 12:53:07 -0400 From: Erb Cooper <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> http://www.openfabrics.org/resources_linux.htm Documentation for the OpenFabrics Linux code base is NOT available here: http://www.openfabrics.org/txt/documentation/ --- Ërb Cooper Strategic Research Liquidnet Holdings, Inc. E [EMAIL PROTECTED] T +(1) 646 674 2022 F +(1) 646 674 2003 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] List of libraries in OFED
Yevgeny Kliteynik wrote: Sasha Khapyorsky wrote: Hi Oren, On 13:31 Wed 09 Jul , Oren Kladnitsky wrote: No. Ibutils use opensm libvendor for mad sending interface. Right, it is not used directly. But it is used in LDFLAGS (due to libosmvendor -> libibumad -> libibcommon dependency): Right, but there's no reason to leave it as "public". libibumad is public, libibcommon isn't -- Yevgeny config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibis/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibmgtsim/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" Sasha ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general Of course - Let me rephrase: No problem for ibutils with removing libibcommon - just tell me when you want to remove it and I'll remove it from the LDFLAGS libs. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] List of libraries in OFED
Sasha Khapyorsky wrote: Hi Oren, On 13:31 Wed 09 Jul , Oren Kladnitsky wrote: No. Ibutils use opensm libvendor for mad sending interface. Right, it is not used directly. But it is used in LDFLAGS (due to libosmvendor -> libibumad -> libibcommon dependency): Right, but there's no reason to leave it as "public". libibumad is public, libibcommon isn't -- Yevgeny config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibis/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibmgtsim/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" Sasha ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] List of libraries in OFED
Hi Oren, On 13:31 Wed 09 Jul , Oren Kladnitsky wrote: > No. Ibutils use opensm libvendor for mad sending interface. Right, it is not used directly. But it is used in LDFLAGS (due to libosmvendor -> libibumad -> libibcommon dependency): config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibis/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibmgtsim/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] List of libraries in OFED
Tziporet Koren wrote: Sasha Khapyorsky wrote: On 09:02 Wed 09 Jul , Tziporet Koren wrote: Public: === * libibcommon I wanted to remove (merge with libibumad and libibmad) libibcommon yet in OFED 1.3 (we discussed this on the list). Not sure I will be able to do it now (in OFED 1.4 timeframe), but at least let's move it from "public" list. Has anyone using this library now? Nobody directly (AFAIK), but via libibumad. I guess -libcommon is listed as part of LDFLAGS in some ibutils Makefile (this is why I didn't want to make a "noise" during 1.3 release cycle). Oren - are you using libibcommon in ibutils? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg No. Ibutils use opensm libvendor for mad sending interface. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/mlx4: Use kzalloc when allocating a new mlx4_ib_qp
Current code uses kmalloc() and then does a bitwise or operation on
qp->flags at create_qp_common():
if (init_attr->create_flags & IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK)
qp->flags |= MLX4_IB_QP_BLOCK_MULTICAST_LOOPBACK;
Instead of taking care of clearing individual fields, just use kzalloc
and forget about similar problems in the future.
Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mlx4/qp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 91590e7..f4fbd5c 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -704,7 +704,7 @@ struct ib_qp *mlx4_ib_create_qp(struct ib_pd *pd,
case IB_QPT_UC:
case IB_QPT_UD:
{
- qp = kmalloc(sizeof *qp, GFP_KERNEL);
+ qp = kzalloc(sizeof *qp, GFP_KERNEL);
if (!qp)
return ERR_PTR(-ENOMEM);
@@ -725,7 +725,7 @@ struct ib_qp *mlx4_ib_create_qp(struct ib_pd *pd,
if (pd->uobject)
return ERR_PTR(-EINVAL);
- sqp = kmalloc(sizeof *sqp, GFP_KERNEL);
+ sqp = kzalloc(sizeof *sqp, GFP_KERNEL);
if (!sqp)
return ERR_PTR(-ENOMEM);
--
1.5.6
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] List of libraries in OFED
Sasha Khapyorsky wrote: On 09:02 Wed 09 Jul , Tziporet Koren wrote: Public: === * libibcommon I wanted to remove (merge with libibumad and libibmad) libibcommon yet in OFED 1.3 (we discussed this on the list). Not sure I will be able to do it now (in OFED 1.4 timeframe), but at least let's move it from "public" list. Has anyone using this library now? Nobody directly (AFAIK), but via libibumad. I guess -libcommon is listed as part of LDFLAGS in some ibutils Makefile (this is why I didn't want to make a "noise" during 1.3 release cycle). Oren - are you using libibcommon in ibutils? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
