On Mon, 2007-02-26 at 06:20, Yevgeny Kliteynik wrote:
> Hi Hal
>
> Trivial data type change to remove compilation warning.
> Please apply to the trunk and to the 1.2 branch.
>
> Thanks.
>
> Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
Thanks. Applied (to both master and ofed_1_2).
--
> Quoting Sasha Khapyorsky <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for OFED 1.2
>
> On 19:44 Tue 27 Feb , Michael S. Tsirkin wrote:
> > > Quoting Sean Hefty <[EMAIL PROTECTED]>:
> > > Subject: Re: [PATCH] for OFED 1.2
> > >
> > > >I think with stacked git or just git and rebasing at key t
On 19:44 Tue 27 Feb , Michael S. Tsirkin wrote:
> > Quoting Sean Hefty <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] for OFED 1.2
> >
> > >I think with stacked git or just git and rebasing at key times, you
> > >could keep an ofed_1_2 tree that folks can easily apply patches to...
> > >
> > >I
> I think it'll be much more work to maintain all these branches.
> And again, there will be conflicts, and it's too easy to get confused when
> resolving a conflict.
Storing patches in a directory seems confusing to me. They must be applied in
a
specific order for everything to work, and that
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: [PATCH] for OFED 1.2
>
> >But you cannot keep a stack for more than one backport pushed, right?
> >So you still need to be slapping the stacks of patches around for each
> >backport.
>
> Why not have separate branches for each kernels too?
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for OFED 1.2
>
> > > >
> > > > Sean, please install quilt and try using it for working with the system.
> > > > Adding new patch is usually done in this way
> > > > quilt new
> > > > quilt add
> > > > edit
> > > > quilt refresh
>
>But you cannot keep a stack for more than one backport pushed, right?
>So you still need to be slapping the stacks of patches around for each
>backport.
Why not have separate branches for each kernels too?
___
openib-general mailing list
openib-general
> > >
> > > Sean, please install quilt and try using it for working with the system.
> > > Adding new patch is usually done in this way
> > > quilt new
> > > quilt add
> > > edit
> > > quilt refresh
> > >
> > > cp patches/ kernel_patches/fixes/
> > > git add kernel_patches/fixes/
> > > git comm
> > Lot's of stuff *is* in wiki already - did you look at pages Vlad
> > created?
>
> A search for "quilt" on the wiki turns up nothing (I checked before I
> posted :-) ).
>
> And yes, I have [thoroughly] read the pages Vlad created. But the
> very fact that this conversation is occurring
> > This is just my $0.01...
>
> It buys very little, if anything. In fact, a whole $0.02 also buys
> very little, if anything. So take my comments for what they're worth.
Oh, good, I thought deflation is getting out of hand ...
--
MST
___
op
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for OFED 1.2
>
> On Tue, 2007-02-27 at 19:44 +0200, Michael S. Tsirkin wrote:
> > > Quoting Sean Hefty <[EMAIL PROTECTED]>:
> > > Subject: Re: [PATCH] for OFED 1.2
> > >
> > > >I think with stacked git or just git and rebasing at ke
On Feb 27, 2007, at 12:45 PM, Michael S. Tsirkin wrote:
> Lot's of stuff *is* in wiki already - did you look at pages Vlad
> created?
A search for "quilt" on the wiki turns up nothing (I checked before I
posted :-) ).
And yes, I have [thoroughly] read the pages Vlad created. But the
very
On Tue, 2007-02-27 at 19:44 +0200, Michael S. Tsirkin wrote:
> > Quoting Sean Hefty <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] for OFED 1.2
> >
> > >I think with stacked git or just git and rebasing at key times, you
> > >could keep an ofed_1_2 tree that folks can easily apply patches to...
> >
> This is just my $0.01...
Thanks for the suggestions, but what does $0.01 buy one in US today?
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit ht
s that are helpful for OFA/
OFED development, they should be detailed on the wiki. The wiki is
where all permanent knowledge should be posted.
This is just my $0.01...
On Feb 27, 2007, at 12:31 PM, Michael S. Tsirkin wrote:
>> Quoting Steve Wise <[EMAIL PROTECTED]>:
>> Su
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for OFED 1.2
>
> >I think with stacked git or just git and rebasing at key times, you
> >could keep an ofed_1_2 tree that folks can easily apply patches to...
> >
> >Its too late to change this for 1.2, but you might want to reconsid
. Tsirkin wrote:
>> Quoting Steve Wise <[EMAIL PROTECTED]>:
>> Subject: Re: [openib-general] [PATCH] for OFED 1.2
>>
>> On Tue, 2007-02-27 at 18:55 +0200, Michael S. Tsirkin wrote:
>>>> Quoting Sean Hefty <[EMAIL PROTECTED]>:
>>>> Subject: Re
>I think with stacked git or just git and rebasing at key times, you
>could keep an ofed_1_2 tree that folks can easily apply patches to...
>
>Its too late to change this for 1.2, but you might want to reconsider
>the design for 1.3.
Can't we just create a new branch (ofed_1_2_patched) with these
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH] for OFED 1.2
>
> On Tue, 2007-02-27 at 18:55 +0200, Michael S. Tsirkin wrote:
> > > Quoting Sean Hefty <[EMAIL PROTECTED]>:
> > > Subject: Re: [PATCH] for OFED 1.2
>
On Tue, 2007-02-27 at 18:55 +0200, Michael S. Tsirkin wrote:
> > Quoting Sean Hefty <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] for OFED 1.2
> >
> > >Please send patches that will be added to kernel_patches/fixes.
> > >
> > >Please update your git tree from
> > >git://git.openfabrics.org/~vlad/o
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for OFED 1.2
>
> >Yes, actual patches should be created under kernel_patches/fixes.
> >
> >Please update your git tree because the following patch fails:
>
> Can you explain how the patch fails? I don't see how putting the patch in
>Yes, actual patches should be created under kernel_patches/fixes.
>
>Please update your git tree because the following patch fails:
Can you explain how the patch fails? I don't see how putting the patch into a
file helps.
>> Why not apply the patches directly?
>>
>To be consistent with 2.6.20 k
> Quoting Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for OFED 1.2
>
> >Please send patches that will be added to kernel_patches/fixes.
> >
> >Please update your git tree from
> >git://git.openfabrics.org/~vlad/ofed_1_2/.git ofed_1_2
>
> You want me to create a patch that adds a file
On Tue, 2007-02-27 at 08:45 -0800, Sean Hefty wrote:
> >Please send patches that will be added to kernel_patches/fixes.
> >
> >Please update your git tree from
> >git://git.openfabrics.org/~vlad/ofed_1_2/.git ofed_1_2
>
> You want me to create a patch that adds a file that contains the actual
>
>Please send patches that will be added to kernel_patches/fixes.
>
>Please update your git tree from
>git://git.openfabrics.org/~vlad/ofed_1_2/.git ofed_1_2
You want me to create a patch that adds a file that contains the actual patches?
Why not apply the patches directly?
_
On Mon, 2007-02-26 at 09:46 -0800, Sean Hefty wrote:
> Vladimir Sokolovsky wrote:
> > On Fri, 2007-02-23 at 12:15 -0800, Sean Hefty wrote:
> > > I would like these fixes in OFED 1.2 as well. What git tree / branch
> > do I
> > > generate a patch against?
> > >
> > > - Sean
> >
> > git://git.
Populate Rx free list with pages.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |9 +
drivers/net/cxgb3/sge.c | 318 +++
2 files changed, 235 insertions(+), 92 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.
Improve the traffic recovery after the HW ran out of response queue entries.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |2 ++
drivers/net/cxgb3/sge.c | 15 ++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/net/
Clean up some private ioctls.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_ioctl.h | 33 +--
drivers/net/cxgb3/cxgb3_main.c | 48 +++
2 files changed, 15 insertions(+), 66 deletions(-)
diff --git a/d
Offload packets may be DMAed long after their SGE Tx descriptors are done
so they must remain mapped until they are freed rather than until their
descriptors are freed. Unmap such packets through an skb destructor.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/sge.c |
Update FW version to 3.2
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c |6 --
drivers/net/cxgb3/version.h |2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
old mode 100755
new m
sysfs attributes are now managed per port, no longer per adapter.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cx
Hey Vlad,
These fixes need to be pulled into ofed_1_2 for the Chelsio Ethernet
driver.
You can pull them directly from my ofa git tree:
git://staging.openfabrics.org/~swise/ofed_1_2 cxgb3_fixes
Thanks,
Steve.
___
openib-general mailing list
openib-
On Sun, 2007-02-25 at 16:48, Sasha Khapyorsky wrote:
> After gprof output analyzing, I noticed that current lmx (switch's lid
> matrix) implementation is extremely slow. This simple hops matrix
> reimplementation makes lid matrices build process two times faster.
Excellent!
> Signed-off-by: Sasha
> int ib_init_ah_from_path(struct ib_device *device, u8 port_num,
> struct ib_sa_path_rec *rec, struct ib_ah_attr
> *ah_attr)
> {
> int ret;
> u16 gid_index;
>
> memset(ah_attr, 0, sizeof *ah_attr);
> ah_attr->dlid = be16_to_cpu(rec->dlid);
Vladimir Sokolovsky wrote:
> On Fri, 2007-02-23 at 12:15 -0800, Sean Hefty wrote:
> > I would like these fixes in OFED 1.2 as well. What git tree / branch
> do I
> > generate a patch against?
> >
> > - Sean
>
> git://git.openfabrics.org/~vlad/ofed_1_2/.git
> branch: ofed_1_2
Can you try pul
nope, doesn't seem to make a difference.
___
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
On Sat, 2007-02-24 at 15:13, Sasha Khapyorsky wrote:
> There are various performance improvements for up/down routing engine:
> - updn_node object which is referenced by switch's priv pointer
> - ranking for switches only
> - replace time consuming cl_list by cl_qlist
> - reuse already collected up
On Sun, 2007-02-25 at 09:23, Yevgeny Kliteynik wrote:
> Hi Hal,
>
> OSM log should be flushed when OSM_SYS_LOG message is
> printed. We had this once, but somehow it has disappeared.
>
> This fix has to go both to trunk and to 1.2.
>
> Thanks,
>
> --Yevgeny
>
> Signed-off-by: Yevgeny Kliteynik
Hi Hal
Trivial data type change to remove compilation warning.
Please apply to the trunk and to the 1.2 branch.
Thanks.
Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
---
osm/opensm/osm_ucast_updn.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/osm/opensm/osm
Sasha Khapyorsky wrote:
> On 16:23 Sun 25 Feb , Yevgeny Kliteynik wrote:
>> Hi Hal,
>>
>> OSM log should be flushed when OSM_SYS_LOG message is
>> printed. We had this once, but somehow it has disappeared.
>>
>> This fix has to go both to trunk and to 1.2.
>>
>> Thanks,
>>
>> --Yevgeny
>>
>> S
Following introduced simplification this patch removes single field
access functions from osm_switch.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
osm/include/opensm/osm_switch.h | 176 ---
osm/opensm/osm_mcast_mgr.c | 27 ++
osm/opensm/
Following previously submitted min hops reimplementation this removes
unused osm_matrix.* files.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
osm/include/Makefile.am |1 -
osm/include/opensm/osm_matrix.h | 456 ---
osm/opensm/Makefile.a
After gprof output analyzing, I noticed that current lmx (switch's lid
matrix) implementation is extremely slow. This simple hops matrix
reimplementation makes lid matrices build process two times faster.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
osm/include/opensm/osm_port_profile
On 16:23 Sun 25 Feb , Yevgeny Kliteynik wrote:
> Hi Hal,
>
> OSM log should be flushed when OSM_SYS_LOG message is
> printed. We had this once, but somehow it has disappeared.
>
> This fix has to go both to trunk and to 1.2.
>
> Thanks,
>
> --Yevgeny
>
> Signed-off-by: Yevgeny Kliteynik <[
Hi Hal,
OSM log should be flushed when OSM_SYS_LOG message is
printed. We had this once, but somehow it has disappeared.
This fix has to go both to trunk and to 1.2.
Thanks,
--Yevgeny
Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
---
osm/opensm/osm_log.c |3 ++-
1 files changed, 2
Hi and sorry about the delay in the reply.
Roland Dreier wrote:
> > In issue number 296 that i opened several months ago in the Bugzilla, i
> > reported about two missing attributes: the first one is the static_rate,
> > and the second one is the src_path_bits which is not being filled right.
>
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH for-2.6.21] IPoIB/cm: improve small
> message bandwidth
>
> OK, I applied the following patch (I had to change one line of your
> patch to get it to apply because the small-message chan
On Fri, 2007-02-23 at 12:15 -0800, Sean Hefty wrote:
> I would like these fixes in OFED 1.2 as well. What git tree / branch do I
> generate a patch against?
>
> - Sean
git://git.openfabrics.org/~vlad/ofed_1_2/.git
branch: ofed_1_2
- Vladimir
>
> ---
>
> rdma_cm: remove unused node_guid from
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] libmthca: optimize calls to htonl with constant parameter
>
> > Newer gccs have the -fwhole-program --combine options that address
> > this and more. One of the things that happens is that all internal
> > functions are made 's
There are various performance improvements for up/down routing engine:
- updn_node object which is referenced by switch's priv pointer
- ranking for switches only
- replace time consuming cl_list by cl_qlist
- reuse already collected up/down related information (in updn_node
structure) instead o
This uDAPL patch adds both dapltest and dtest utilities, including manual
pages, to the DAPL project
build. The dapltest required some modifications to build on x86_64.
James, please review.
Signed-off by: Arlin Davis [EMAIL PROTECTED]
diff --git a/Makefile.am b/Makefile.am
index 1190f20..e2bf4
thanks, queued for 2.6.21
___
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
I would like these fixes in OFED 1.2 as well. What git tree / branch do I
generate a patch against?
- Sean
---
rdma_cm: remove unused node_guid from cma_device structure.
ib_cm: remove ca_guid from cm_device structure.
rdma_cm: request reversible paths only.
ib_core: Set hop limit in ib_init_ah
> Newer gccs have the -fwhole-program --combine options that address
> this and more. One of the things that happens is that all internal
> functions are made 'static' and all compilation units are optimized in
> one go.
Good point... but is there any sane way to use that feature with
automake
On Thu, 2007-02-22 at 17:18, Sean Hefty wrote:
> >>Can someone help my understanding here? Is ipoib joining a multicast group
> >>using the full membership PKey, even if the node that it joins from only
> >>has the
> >>limited membership PKey configured? And the code in ib_find_cached_pkey
> >>h
On Thu, 2007-02-22 at 17:18, Sean Hefty wrote:
> >>Can someone help my understanding here? Is ipoib joining a multicast group
> >>using the full membership PKey, even if the node that it joins from only
> >>has the
> >>limited membership PKey configured? And the code in ib_find_cached_pkey
> >>h
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] libmthca: optimize calls to htonl with constant parameter
>
> > So what is different in your setup that causes this patch to make a
> > difference for you?
>
> Hmm. I agree it is somewhat strange.
>
> Below is a simple test
> So what is different in your setup that causes this patch to make a
> difference for you?
Hmm. I agree it is somewhat strange.
Below is a simple test that attempts to compare htonl, CONSTANT_HTONL,
and an array-driven implementation. The code line is taken directly from htonl.
Could you compile
On Thu, Feb 22, 2007 at 10:09:28PM -0800, Roland Dreier wrote:
> (BTW, one thing I did notice while looking at the i386 assembly is
> that one micro-optimization that might make sense to use something
> like __attribute__((regparm(3))) for internal function calls within
> libibverbs and libmthca o
> GCC seems to be unable to propogate constants across calls to htonl.
> So it turns out to be worth the while to replace htonl with
> a hand-written macro in case of constant parameter.
I'm wondering why this helps you. On my system (which has Debian's
old glibc 2.3.6, certainly nothing parti
>the patches are in
>
>git://git.openfabrics.org/~shefty/rdma-dev.git for-roland
I will do that in the future.
And yes, the sign off line was just a mistake. Thanks for fixing that.
- Sean
___
openib-general mailing list
openib-general@openib.org
Anyway, all 4 queued up in my for-2.6.21 branch
___
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
> The patches are in git.openfabrics.org/~shefty/rdma-dev.git,
> for-roland branch, which is based on 2.6.21-rc1.
One other request: please include a URL that I can just copy and
paste, so I don't actually have to read and parse complete sentences.
Something like:
the patches are in
git://
> I notice that the actual patches you committed don't have your
> sign-off in the git changelog. I assume this is a mistake so I'll add
> it back in...
which means I can't just pull your branch. But that's OK, still doing
git format-patch, edit patches, git am is pretty easy.
__
These all look fine, I'll queue them up.
> Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
I notice that the actual patches you committed don't have your
sign-off in the git changelog. I assume this is a mistake so I'll add
it back in...
___
openib-gene
Roland,
Please consider the following minor fixes for 2.6.21:
rdma_cm: remove unused node_guid from cma_device structure.
ib_cm: remove ca_guid from cm_device structure.
rdma_cm: request reversible paths only.
ib_core: Set hop limit in ib_init_ah_from_wc correctly.
The patches are in git.openfab
GCC seems to be unable to propogate constants across calls to htonl.
So it turns out to be worth the while to replace htonl with
a hand-written macro in case of constant parameter.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Ishai Rabinovitz <[EMAIL PROTECTED]>
---
Rolan
Steve Wise wrote:
> Divy,
>
> Do these need to be pulled into OFED 1.2 as well?
>
Hi Steve,
Yes, I believe so.
Cheers,
Divy
> Steve.
>
>
> On Thu, 2007-02-22 at 03:58 -0800, Divy Le Ray wrote:
>
>> Jeff,
>>
>> I'm sending a series of incremental patches updating
>> the cxgb3 driver. These
>>Can someone help my understanding here? Is ipoib joining a multicast group
>>using the full membership PKey, even if the node that it joins from only has
>>the
>>limited membership PKey configured? And the code in ib_find_cached_pkey helps
>>enable this?
>
> Yep. The ipoib create_child functi
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH for-2.6.21] IPoIB/cm: improve small message bandwidth
>
> OK, I applied the following patch (I had to change one line of your
> patch to get it to apply because the small-message changed the context
> so one chunk didn't apply).
>
OK, I applied the following patch (I had to change one line of your
patch to get it to apply because the small-message changed the context
so one chunk didn't apply).
Anyway I don't see any difference in small message latency or large
message throughput. (Actually latency seems slightly worse but
> 1. Is there something special you do when you run the benchmark (msi,
> taskset, ...)?
Yes, I am using MSI-X, and I pin the interrupt handler to one CPU
(CPU#0 in my particular case). Then I use taskset to pin the NPtcp
process to a CPU in a different package (CPU#2 in my system).
BTW with
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH for-2.6.21] IPoIB/cm: improve small message bandwidth
>
> Thanks, queued for 2.6.21. With this patch I see small-packet latency
> down almost all the way back to what datagram mode gives -- on a pair
> of fast woodcrest systems I
On 2/22/07, Sean Hefty <[EMAIL PROTECTED]> wrote:
> >My understanding is that when an IPoIB broadcast domain contains both
> >partial and full members (*) attempts to communicate between two partial
> >members would silently fail, does this silence is something you think we
> >should work to change
On 2/22/07, Sean Hefty <[EMAIL PROTECTED]> wrote:
> >An IB multicast group _cannot_ have partial members so this never should
> >get far enough to where two limited members would be unable to
> >communicate.
> Can someone help my understanding here? Is ipoib joining a multicast group
> using the
Thanks, I applied this and pushed it out.
___
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
Missed 2 lines in the patch.
Below is the correct patch:
---
The following patch removes manpage symbolic links so that
they may be relinked in the install.
Suggested by Michael Tsirkin.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
diff --git a/Makefile.am b/Makefile.am
index 5d2383e..7
>An IB multicast group _cannot_ have partial members so this never should
>get far enough to where two limited members would be unable to
>communicate.
Can someone help my understanding here? Is ipoib joining a multicast group
using the full membership PKey, even if the node that it joins from on
>My understanding is that when an IPoIB broadcast domain contains both
>partial and full members (*) attempts to communicate between two partial
>members would silently fail, does this silence is something you think we
>should work to change?
I'm looking at this from a different view than just ipo
On Thu, 2007-02-22 at 03:04, Or Gerlitz wrote:
> Sean Hefty wrote:
> >> Note that since the HCA validates the pkey in the in coming packet, no
> >> matter what the IB SW would do, partial members of a partition can't
> >> talk to each other. So the approach taken by the core/ipoib code was
> >> to
On Thu, 2007-02-22 at 02:28, Or Gerlitz wrote:
> Hal Rosenstock wrote:
> > On Wed, 2007-02-21 at 15:45, Or Gerlitz wrote:
> >> On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>
> >> If the IPoIB spec does not allow both partial and full members of a
> >> partition to share
Divy,
Do these need to be pulled into OFED 1.2 as well?
Steve.
On Thu, 2007-02-22 at 03:58 -0800, Divy Le Ray wrote:
> Jeff,
>
> I'm sending a series of incremental patches updating
> the cxgb3 driver. These patches are built against Linus'git tree.
>
> Cheers,
> Divy
> -
> To unsubscribe fro
The following patch removes manpage symbolic links so that
they may be relinked in the install.
Suggested by Michael Tsirkin.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
diff --git a/Makefile.am b/Makefile.am
index 5d2383e..455041e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -70,6 +70,
On Wed, 2007-02-21 at 14:46 -0600, Steve Wise wrote:
> Stop the ep timer in ec_status() if the status indicates a
> bad close.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> ---
>
> drivers/infiniband/hw/cxgb3/iwch_cm.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff
On Thu, 2007-02-15 at 14:00 -0600, Steve Wise wrote:
> Fix copyrights in the iw_cxgb3 driver.
>
> Remove the Open Grid Computing copyright. It shouldn't be there.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> ---
Applied.
--
Vladimir Sokolovsky <[EMAIL PROTECTED]>
Mellanox Technologies
On Thu, 2007-02-15 at 13:59 -0600, Steve Wise wrote:
> Fix copyrights in the cxgb3 driver.
>
> Remove the Open Grid Computing copyright. It shouldn't be there.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> ---
Applied.
--
Vladimir Sokolovsky <[EMAIL PROTECTED]>
Mellanox Technologies Ltd
Sean Hefty wrote:
>> Note that since the HCA validates the pkey in the in coming packet, no
>> matter what the IB SW would do, partial members of a partition can't
>> talk to each other. So the approach taken by the core/ipoib code was
>> to just ignore the MSb in places where the code looks for th
Hal Rosenstock wrote:
> On Wed, 2007-02-21 at 15:45, Or Gerlitz wrote:
>> On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
>> If the IPoIB spec does not allow both partial and full members of a
>> partition to share a broadcast domain (eg the IPv4 broadcast group
>> associa
On Wed, 2007-02-21 at 17:53, Hal Rosenstock wrote:
> On Wed, 2007-02-21 at 17:36, Sean Hefty wrote:
> > > It does this since its makes life simple and robust.
> >
> > Is an SM prevented from loading two PKeys into an HCA's PKey table that
> > differ
> > by only the membership bit?
>
> Nope.
>
On Wed, 2007-02-21 at 17:36, Sean Hefty wrote:
> > It does this since its makes life simple and robust.
>
> Is an SM prevented from loading two PKeys into an HCA's PKey table that
> differ
> by only the membership bit?
Nope.
> I can't think of any reason to do such a thing,
Me neither. It wou
> It does this since its makes life simple and robust.
Is an SM prevented from loading two PKeys into an HCA's PKey table that differ
by only the membership bit?
I can't think of any reason to do such a thing, but depending on which index
was
selected could limit which nodes you could communic
On Wed, 2007-02-21 at 15:45, Or Gerlitz wrote:
> On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-02-21 at 07:35, Or Gerlitz wrote:
>
> > > > I believe it is a spec (compliance) violation for the port to be a
> > > > partial member and join as a full member
On 2/21/07, Sean Hefty <[EMAIL PROTECTED]> wrote:
> >There is no problem. As i have explained over this thread the ipoib
> >and the core abstract away from the user the actual value of the MSb
> >of the pkey, that is whether it is a full or partial membership pkey.
>
> But *why* does the kernel cod
And this one too...
Thanks,
Steve.
On Thu, 2007-02-15 at 14:00 -0600, Steve Wise wrote:
> Fix copyrights in the iw_cxgb3 driver.
>
> Remove the Open Grid Computing copyright. It shouldn't be there.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> ---
>
> drivers/infiniband/hw/cxgb3/core
Vlad,
Please apply this to ofed_1_2.
Thanks,
Steve.
On Thu, 2007-02-15 at 13:59 -0600, Steve Wise wrote:
> Fix copyrights in the cxgb3 driver.
>
> Remove the Open Grid Computing copyright. It shouldn't be there.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> ---
>
> drivers/net/cxgb3
Stop the ep timer in ec_status() if the status indicates a
bad close.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/c
On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-21 at 07:35, Or Gerlitz wrote:
> > > I believe it is a spec (compliance) violation for the port to be a
> > > partial member and join as a full member.
> > Since partial members can't talk among themselves,
Stop the ep timer in ec_status() if the status indicates a
bad close.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cx
>There is no problem. As i have explained over this thread the ipoib
>and the core abstract away from the user the actual value of the MSb
>of the pkey, that is whether it is a full or partial membership pkey.
But *why* does the kernel code do this, and should it?
- Sean
1 - 100 of 8276 matches
Mail list logo
