On 5/4/2017 3:14 PM, Woodruff, Robert J wrote:
> Doug Ledford wrote,
>> The OFA has already learned their lesson once with XRC. I wonder
>> if they are getting ready to get hit with another lesson over this.
>> The issue is if the OFA ships an API and it isn't upstream,
ide, the OFA at least has a pretense of wanting to get
along with the upstream linux community. As long as they want to
preserve that relationship, then they should listen when the community
has something to say. It might well be their decision, but the
ramifications of that decision might sabotage thei
the only people who have legitimate complaints here are those
> people running Xeon Phi with Mellanox HCAs who are being forced to
> use OFED, rather than upstream code.
I suspect there are legitimate grounds to complain about the fact that
it is shipped in the OFA OFED and not li
ys of doing peer to peer PCI
operations and such without any input from the Xeon Phi folks.
--
Doug Ledford
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: OpenPGP digital signature
sed in the least if backports to an EL6 kernel are
a simple no-go for current upstream code.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/mailman/listinfo/ewg
MA stack and out. I suspect this backport cycle may be worse than
those in the past. But I could be wrong...
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
___
ewg mailing list
ewg@lists.open
On 05/16/2016 12:36 PM, Steve Wise wrote:
>
>
>> -Original Message-----
>> From: Doug Ledford [mailto:dledf...@redhat.com]
>> Sent: Monday, May 16, 2016 11:27 AM
>> To: Steve Wise; ewg@lists.openfabrics.org
>> Subject: Re: libibverbs not compiling against
On 05/16/2016 12:09 PM, Steve Wise wrote:
> See: http://bugs.openfabrics.org/bugzilla/show_bug.cgi?id=2598
>
> Looks like some compilation problem against RHEL6.6. Who should own
> this? It is assigned to Doug Ledford, but I'm not sure he's the correct
> person?
I&
ot;, ret);
> + goto destroy;
> + }
> + pthread_mutex_unlock(&ctx->qp_table_mutex);
> +
> + return (struct ibv_qp *)&qp->verbs_qp;
> +
> +destroy:
> + ibv_cmd_destroy_qp(&qp->verbs_qp.qp);
> +err:
> + free(qp);
> + return NUL
On 4/1/2014 12:05 PM, Bart Van Assche wrote:
> Hello,
>
> When I try to clone a git repository from git.openfabrics.org my git
> client reports "connection refused". Is that a known issue ?
I get the same thing. If the git daemon is up and running, I'm guessing
the iptables need tweaked to allow
in
> the log in memory as well? I haven’t put a limit on the size of the log
> in /etc/rdma/opensm.conf.
You're hitting a bug in the opensm startup script on that release. It's
trying to run with a non-existent config file (this was fixed by adding
shopt -s nullglob to the startup
On 8/20/2012 9:42 AM, Vladimir Sokolovsky wrote:
> On 08/17/2012 10:21 PM, Luick, Dean wrote:
>> The qperf-0.4.7-0.1. gf3f7001.tar.gz contained a packaging mistake. I
>> have created an updated 0.2 version. I have verified that it
>> install.pl will correctly build it in the OFED-3.5-20120816-060
g important enough, then they should be able to
exist with just IPoIB. There is very little impetus to maintain two
versions of software to make sockets based apps work on RDMA fabrics
when the relative gain of one over the other isn't that high and it has
legal encumbrances to negate the posi
-example.c, the address for the FSF is incorrect). Just
an FYI for any companies whose legal teams are as strict as ours about
not redistributing code without a proper, legal license. I hope an
rds-tools-2.0.8 should be rolled soon to resolve the issue.
--
Doug Ledford
GPG KeyID
no fixes)
> - OFED package will be used for easy installation of all packages in a
> friendly manner
Yay!!! I'm all in favor.
--
Doug Ledford
GPG KeyID: 0E572FDD
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.op
de. So, to be
as safe as possible, you write your program to be as simple as possible,
to do only what it absolutely must suid root, and have the best auditor
audit it.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband
or is to assess and
> minimize the threat. Smaller programs where you can inspect and
> understand the program are more trustable than large complex programs.
This part is very true.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
just needs to go away. It's been far too abused for far too long
and it's mere existence is hindering upstream development. I appreciate
that you attempt to do the right thing most of the time, but it really
needs to be all of the time, and you need your users right there beside
you in orde
h in OFED and someone will rush to its
>> defense with a 'we tried to follow the process and it failed, so we
>> did it anyway' argument.
>>
>> I also didn't say this is the only way that RDMA development goes,
>> lots and lots of stuff goes into mainl
No clue.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
PGP.sig
Description: This is a digitally signed message part
___
ewg mailin
r, which is exactly the same thing: on large allocations
forward to __g_f_p(). See include/linux/slub_def.h's definition of
kmalloc_large and kmalloc.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Inf
On Jul 23, 2009, at 4:20 AM, Jack Morgenstein wrote:
On Thursday 16 July 2009 21:08, Doug Ledford wrote:
On rhel4 and rhel5 machines, the kmalloc implementation does not
automatically forward kmalloc requests > 128kb to __get_free_pages.
Please include this patch in all rhel4 and rhel5 backp
loc requests larger than 128k (at least in this code path,
there may be others lurking too, I'll forward additional patches if I
find they are needed).
bz508902.patch
Description: Binary data
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific R
reeze & alpha release and doing this change for the beta.
>
> tziporet
>
> ___
> ewg mailing list
> ewg@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
- --
Doug Ledford
GPG KeyID: CFBFF194
ssion that you start off by telling customers that OFED is a
prerequisite to running Intel MPI in the first place. If that's the
case, then I would question whether that's decoupled from OFED, or just
not in the OFED tarball.
--
Doug Ledford
GPG KeyID: CFB
thing
affair. This is in direct contrast to the rest of our entire operating
system where we isolate and target things that need fixed and only
things that need fixed.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs
API issues maybe resolved even when
> MPIs are part of package.
You're right, API issues *can* be resolved even if the latest MPIs are
shipped with OFED. It's just that this hasn't been the case in the
past, and throwing everything in the same bucket is a strong incentive
not
years helping
> the OFED community and would like to continue with this process.
>
> Thanks,
>
> DK
>
>
>
> ___
> ewg mailing list
> ewg@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listi
On Wed, 2009-06-03 at 19:14 +0200, Pawel Dziekonski wrote:
> On Wed, 03 Jun 2009 at 10:14:07AM -0400, Doug Ledford wrote:
> > On Jun 3, 2009, at 3:39 AM, Pawel Dziekonski wrote:
> >> On Tue, 02 Jun 2009 at 10:30:07PM +0300, Tziporet Koren wrote:
> >>
> >&g
ist
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
InfiniBand Specific RPMS
http://people.redhat.com/dledford/Infiniband
PGP.sig
Description: This
nel in RHN
(but I could be wrong on that, I don't keep up with RHN channel
assignments myself).
So, our preference is actually to have the right firmware be part of the
driver itself. That's what cxgb3 does now, it's what QLogic FC adapters
have done since forever, as well as quite
On Wed, 2009-01-28 at 09:38 -0600, Steve Wise wrote:
> Doug Ledford wrote:
> > On Thu, 2009-01-22 at 16:07 -0600, Steve Wise wrote:
> >
> >> I understand the desire to not release new features in a point release,
> >> but at the same time, these features
aintenance release of OFED (1.4.1) to be generated? I am already hearing
> >> requests for an OFED release that will support it.
> >>
> >>
> >>
> >> John Russo
> >>
> >> QLogic
> >>
> >> ___
______
> 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.openfabri
g OFED kernel patches
into our kernel. With the exception of SDP (which was intentionally
allowed) and qlgc_vnic (which was unintentionally allowed), if it's not
either in the upstream linux kernel, or slated for inclusion, then I
don't include it in our kernel. Hence why xrc and
On Sun, 2009-01-04 at 11:12 +0200, Vladimir Sokolovsky wrote:
> Doug Ledford wrote:
> > So I downloaded the OFED-1.4.tar.gz file, unpacked it, went into
> > OFED-1.4/SRPMS and ran rpm2cpio on ofa_kernel-ofed-1.4.src.rpm, then ran
> > cpio on the output, then unpacked the ofa_k
the third one. Does the
ofa_kernel tarball properly patch up for other people?
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
D
can also remove the if inside the loop as you'll just
> > overwrite the last entry when you exit the loop.
> >
> Well, yes, but then I am going to reference an entry outside the
> bounds of the array, which we want to prevent in the first place.
No, you won't be r
> + priv->rx_wr_draft[UD_POST_RCV_COUNT - 1].next = NULL;
>
> if (ipoib_ud_need_sg(priv->max_ib_mtu)) {
> for (i = 0; i < UD_POST_RCV_COUNT; ++i) {
>
> What do you think?
If you're going to keep the setting of the last item to NULL ou
udes a dist tag on the release, aka:
Release:1%{?dist}
which on Fedora 9 works out to be 1.fc9 unless you undefine the dist
macro. I'm guessing the install script doesn't know about the dist
macro and isn't smart enough to automatically look for packages with
either the non-d
ck just wasn't feasible. So, instead, I had
diffed the patches to get a diff of diffs, read those, and hand moved
any relevant changes into the code. Painful.
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infinib
etc.). Also somebody may want to use it - let people to decide.
I'll second Sasha's opinion here. Being in the default library search
path is fine, even for private libraries. The pain of having them
outside the default search path far outweighs the benefit of them not
being
On Thu, 2008-01-31 at 21:27 +0200, Gleb Natapov wrote:
> On Thu, Jan 31, 2008 at 01:30:23PM -0500, Doug Ledford wrote:
> > > And I'm really not trying to come across harsh here, but if the distros
> > > are
> > > willing to pull the OFED code, wh
ulling them from OFED at this point (or at least have been submitted
upstream and is being worked towards acceptance).
In terms of user space, given a choice between a released tarball or the
custom OFED tarball, I choose the released tarball. So, I currently
have Roland's libibverbs, lib
ing upstream. So, at least for the
kernel, that's mostly true as OFED is pretty close to Roland's tree
generally speaking. As for the user space packages though, you guys
*are* the upstream. There's no one to merge upstream to and very little
oversight by anyone. So, it's entirel
On Wed, 2008-01-30 at 18:40 +0200, Tziporet Koren wrote:
> Doug Ledford wrote:
> >
> > Hmmm...I'd like to put my $.02 in here. I don't have any visibility
> > into what drives the OFED schedule, so I have no clue as to why people
> > don't want to slip t
(Mellanox to
> debug)
>
> 767 major [EMAIL PROTECTED] Non backport Kernels
> that don't build in genalloc cause compile errors for cxgb3 - no fix
> (document)
And we still need to get actual downloads for a number of the srpms in
OFED-1.3. The various spec files list f
f63cb1f13bfb infiniband-diags-1.3.3.tar.gz
> 25b9491f90c7e851f5bafd556bcac5f6 libibcommon-1.0.6.tar.gz
> 0fa433e69cb04559efbc76a7157cc700 libibmad-1.1.3.tar.gz
> b4297b00f3999c951f8b98df6f5e6b19 libibumad-1.1.4.tar.gz
> 979b05d0534b1ee5f4a2eb12576a76e7 opensm-3.1.6.tar.gz
Thank you, t
e all known to work properly together. From that point, I just grab
the appropriate tarballs that contain the releases mentioned, and I
build them all through the build system and that's our release cycle.
> Tziporet
>
>
> _______
>
On Mon, 2007-08-27 at 16:11 -0400, Doug Ledford wrote:
> OK, it's a bug in the rpm packaging. In particular, /var/lib/rpm/macros
> has the base settings for rpm when building. Then, for arch specific
> settings, there is /var/lib/rpm/linux-%{arch}/macros. RPM *should* also
>
On Mon, 2007-08-27 at 11:32 +0300, Vladimir Sokolovsky wrote:
> Doug Ledford wrote:
> > On Fri, 2007-08-24 at 13:47 +0200, Stefan Roscher wrote:
> >> Hi Vladimir,
> >>
> >> I tested the new build environment with some different configurations.
> >> Fro
> >
> > --all|--hpc|--basic Install all,hpc or basic packages
> > correspondently
> >
> >
> > Known Issues:
> > IPoIB configuration is not supported yet.
> >
> > Please comment.
> >
> > Regards,
> > Vladimir
lly just looking for tarballs to download. Like Roland mentioned,
what I need is a release, not a distribution.
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://
re unreleased bits, but give you a peek into what changes might
> > be coming in the next kernel update. Not sure if this is of use to you.
>
> I don't have a ppc machine so I can't use your install ISOs.
Nonsense. Of course you can. At a minimum rpm2cpio | cpio -ivd gets
a
4.5 resp sles10 ppc64
> in their daily build runs too.
> Thanks
> Nam
All of the kernel rpms from our U5 kernel have been on my web page in my
sig for *ages*. All you need to do is download the needed rpms and
install.
--
Doug Ledford <[EMAIL PROTECTED]>
that needs this most of all.
> >
> > I think it's ofed group who should ask redhat and suse for help in this
> > matter, because in the long run, this is about ofed development and build.
> > Tziporet, please add this topic to today's ofed call.
>
>
>
-
with a URL to download
> > above kernel source tree in order to perform daily build of ofed
> > code suite? This will help us to prevent build issues in very early
> > stage.
> > Thanks much in advance!
> >
> > Regards
> > Nam
>
> Nam,
> w
includes the files that it thinks are relevant to that
arch, and by compiling against a complete source tree, you missed the
fact that the ppc64 arch wouldn't compile against the kernel-devel.ppc64
package entirely.
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBF
$RELEASE'/;s/@TARBALL@/'$TARBALL'/' <
> > $1/$1.spec.in > $1-$VERSION/$1.spec
>
> This, I think, is the bit that we definitely want to reuse.
>
> > if [ -f $1-$VERSION/autogen.sh ]; then
> > cd $1-$VERSION
> > ./autoge
On Wed, 2007-07-18 at 05:18 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
> >
> > On Wed, 2007-07-18 at 00:09 +0300, Michael S. Tsirkin wrote:
> > > &g
On Wed, 2007-07-18 at 05:18 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > Subject: Re: [ofa-general] Re: RFC OFED-1.3 installation
> >
> > On Wed, 2007-07-18 at 00:09 +0300, Michael S. Tsirkin wrote:
> > > &g
you?
Sure, as much as possible. I generally don't recommend using it in
production, but just as close as they can get to production is fine with
me. The more issues they find while I'm still actually working on it
and making new revisions, the less issues they'll find
eed to be able to tell the difference. What if
they installed it to test and provide feedback to you, but then because
the version numbers weren't distinct, and they forgot just which
machines they put it in, *they* no longer knew which was the beta/rc
code or the final release?
--
Doug Led
your RPM and mine collide in a way that renders the machine
dysfunctional.
So don't think of it as playing games with bumping release numbers,
think of it as finally making OFED RPMs standard compliant so you no
longer need the workaround of ofed_info.
--
Doug Ledford <[EMAI
ase"
>
> For what it's worth, I agree with this approach.
Ditto.
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledfor
urce package, we edited extraversion to
-prep so that the final result if a customer used it to build a kernel
would be something like 2.6.9-prep in the kernel version. You guys
could do something similar in all the src.rpms you ship. Since you know
they will be compiled locally, you c
em, a reality. It's the
difference between RHEL and Fedora.
> The way OFED release process works, we really don't
> do releases all that often, and when we do, we can coordinate with
> the maintainer.
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
On Tue, 2007-07-17 at 19:45 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > Subject: Re: RFC OFED-1.3 installation
> >
> > On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
> > > > Quoting Doug Ledford <
On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <[EMAIL PROTECTED]>:
> > Subject: Re: RFC OFED-1.3 installation
> >
> > On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote:
> > > > Let me give an example.
needs to be
> addressed
> at the package level, not at OFED level though. Right?
Versioning needs to be addressed at both levels. You need versions of
software to start with, but then you still need releases of packages to
differentiate between different builds of a specific ver
automatically.
There's probably more things to list, but I really don't feel like
repeating what amounts to our standard build requirements when they are
already all written out in the guides I talked about in my Sonoma talk.
Hopefully, all of this will help you get a clear
On Fri, 2007-07-06 at 17:01 -0400, Hal Rosenstock wrote:
> On Fri, 2007-07-06 at 14:33, Doug Ledford wrote:
> > On Fri, 2007-07-06 at 09:00 -0400, Hal Rosenstock wrote:
> > > On Wed, 2007-07-04 at 12:34, Doug Ledford wrote:
> > > > On Fri, 2007-06-29 at 09:
On Fri, 2007-07-06 at 09:00 -0400, Hal Rosenstock wrote:
> On Wed, 2007-07-04 at 12:34, Doug Ledford wrote:
> > On Fri, 2007-06-29 at 09:37 -0400, Hal Rosenstock wrote:
> > > There is a new release of the management libraries which include the
> > > ANSIfie
ibcommon-1.0.4.tar.gz
> 288b865a0015ac3251cffa011a7633eb libibumad-1.0.6.tar.gz
> 04a5b6dcd2ee930f44d5715ee013f78b libibmad-1.0.6.tar.gz
Hey Hal, I noticed you have release tarballs there for the libs, and one
for the older named openib-diags. What would it take to get a release
tarball for infiniband-diags an
On Tue, 2007-06-26 at 12:49 -0700, Scott Weitzenkamp (sweitzen) wrote:
> > I hope there will be some attempt to get these drivers merged
> > upstream too.
>
> How about SDP, are we ready to try to merge it upstream?
I hope so.
--
Doug Ledford <[EMAIL PROTECTED]>
___
> ewg mailing list
> ewg@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
--
Doug Ledford <[EMAIL PROTECTED]>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available a
76 matches
Mail list logo
