an Liss
Cc: Richard Frank; o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> RFC 4291, Appendix A.
Thanks for the pointer. As far as I can tell from reading some IPv6
stuff, it really is broken to try to go from a link-local IPv6 address
bac
> RFC 4291, Appendix A.
Thanks for the pointer. As far as I can tell from reading some IPv6
stuff, it really is broken to try to go from a link-local IPv6 address
back to a L2 ethernet address. For example, RFC 2464 (pointed to by RFC
4291) says:
Ethernet Address
The 48 bit
stack
implementation.
--Liran
-Original Message-
From: Roland Dreier [mailto:rdre...@cisco.com]
Sent: Monday, November 23, 2009 9:20 PM
To: Liran Liss
Cc: Richard Frank; o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> In
RFC 4291, Appendix A.
--Liran
-Original Message-
From: Roland Dreier [mailto:rdre...@cisco.com]
Sent: Monday, November 23, 2009 9:18 PM
To: Liran Liss
Cc: Richard Frank; o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> RFC 30
On Tue, Nov 24, 2009 at 04:18:35PM +0200, Or Gerlitz wrote:
>
> I see this code in a patch whose commit log has the following "Date: Mon, 3
> Aug 2009 18:29:07 +0300" and "Subject: [PATCH 11/13] mlx4: Add support for
> RDMAoE - address resolution"
>
> +struct ib_ah *mlx4_ib_create_ah(struct ib_
Liran Liss wrote:
> LL: Any comments on our low-level driver are more than welcome.
I see this code in a patch whose commit log has the following "Date: Mon, 3 Aug
2009 18:29:07 +0300" and "Subject: [PATCH 11/13] mlx4: Add support for RDMAoE -
address resolution"
+struct ib_ah *mlx4_ib_create_a
penfabrics.org [mailto:ewg-
> boun...@lists.openfabrics.org] On Behalf Of Richard Frank
> Sent: Monday, November 23, 2009 4:59 PM
> To: Jeff Squyres
> Cc: o...@lists.openfabrics.org; Roland Dreier (rdreier); OpenFabrics
EWG;
> Liran Liss
> Subject: Re: [ewg] Re: [ofw] SC'09 BOF
> In any case, this is not a correctness issue that prohibits
> experimentation with rdmaoe multicast on any network today.
I agree -- nothing prevents experimentation. I am just leery about
making invasive changes to the core stack in the absence of any
documented design for IBoE (that I've s
> RFC 3041 deals with static global IP addresses on the Internet,
> especially for portable devices.
> rmdaoe allows using link-local GIDs for applications residing on the
> same subnet, so I don't see the relevance.
I guess you're right -- I was confused about when random addresses are
used
See below.
--Liran
I understand that this is your assessment of the situation, looking on
the series present at the ofed1.5 rdmaoe branch in a black box manner
yields that many many files are touched, see below. Coming and saying
that changes in your HW LL driver are out of the scope for other
com
gt; In any case, this is not a correctness issue that prohibits
> >> experimentation with rdmaoe multicast on any network today.
> >> --Liran
> >>
> >>
> >> -Original Message-
> >> From: ewg-boun...@lists.openfabrics.org
> &
nfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> Having lots of testing exposure can help in validating that all the
> edge cases are handled..
To some extent -- but there also needs to be some thinking involved to
make sure that the interf
nfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> Having lots of testing exposure can help in validating that all the
> edge cases are handled..
To some extent -- but there also needs to be some thinking involved to
make sure that the interf
Liran Liss wrote:
> The patches don't change the logic of existing flows at all, so we are
> not risking *anything* in terms of the stability of the current stack.
I understand that this is your assessment of the situation, looking on the
series present
at the ofed1.5 rdmaoe branch in a black bo
Jeff Squyres wrote:
FWIW: the dealbreaker for me is that we're already at 1.5rc2. By
OFED's own rules, new features are not to be allowed. Or you can
reset the release clock and target Jan/Feb.
Mellanox already has their own OFED distribution -- since there
appears to be strong desire to ge
icast on any network today.
--Liran
-Original Message-
From: ewg-boun...@lists.openfabrics.org
[mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Roland Dreier
Sent: Thursday, November 19, 2009 9:35 PM
To: Richard Frank
Cc: o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg]
9:35 PM
To: Richard Frank
Cc: o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> Having lots of testing exposure can help in validating that all the
> edge cases are handled..
To some extent -- but there also needs to be some thinking invol
facts... the patch set sent from downtown Yoqne'am isn't an addition of feature
turns out that some folks from the Mellanox R&D group found this
sentence insulting, and I am apologizing for that.
Mentioning the geographic location of the developers didn't come to
serve why I find the patch s
ginal Message-
From: ewg-boun...@lists.openfabrics.org
[mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Or Gerlitz
Sent: Friday, November 20, 2009 1:39 AM
To: Richard Frank
Cc: Sean Hefty; Roland Dreier; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
Ric
On Mon, Nov 23, 2009 at 10:11:21AM +0200, Eli Cohen wrote:
Would like to fix a typo: I meant bellow:
Saying that the patch set did not go through a review process would
**be** inaccurate.
> On Fri, Nov 20, 2009 at 01:38:59AM +0200, Or Gerlitz wrote:
> >
> > yes, this would be simply not supporta
] On Behalf Of Roland Dreier
Sent: Thursday, November 19, 2009 9:17 PM
To: Richard Frank
Cc: o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
> How can 1500 lines out of 240k lines be a big change.. do I have
these > numbers right - is
On Fri, Nov 20, 2009 at 01:38:59AM +0200, Or Gerlitz wrote:
>
> yes, this would be simply not supportable, think about that, you want
> to hand your customers with a code which didn't pass review nor
> acceptance by the Linux IB stack maintainers (Roland and Sean), say,
> next a crash happens at t
+1 on Roland's and Woody's comments.
There is a difference between the *desirability* of a new feature and
the speed to which it should be pushed out to an enterprise/production-
quality software stack.
1. We're at rc2. Major changes to the core shouldn't even be on the
table.
2. Both R
Obviously I meant the IBoE functionality, not the entire stack.
Carl
Or Gerlitz wrote:
get the RDMAoE code into 1.5, marked as evaluation if that is EWG's assessment
rather than push it off to 1.6. This is important technology that should not be
held back
It would be great if RoCEE were par
Or wrote,
>> get the RDMAoE code into 1.5, marked as evaluation if that is EWG's
>> assessment
>> rather than push it off to 1.6. This is important technology that should not
>> be held back
>> It would be great if RoCEE were part of 1.5 even if it were
>> listed as "evaluation".. for now.
> It was disclosed at the BOD meeting that there is no defined
> process for inclusion of new features in OFED releases
facts... the patch set sent from downtown Yoqne'am isn't an addition
of feature but rather pose changes everywhere in the IB stack, so
maybe the BOD should get together again and
> get the RDMAoE code into 1.5, marked as evaluation if that is EWG's assessment
> rather than push it off to 1.6. This is important technology that should not
> be held back
> It would be great if RoCEE were part of 1.5 even if it were
> listed as "evaluation".. for now.
> this is leading edge
Richard Frank wrote:
> How can 1500 lines out of 240k lines be a big change.. do I have these
> numbers right
> - is the big change you are referring too?
Rick, the change set is way not self contained but rather touches
various parts of the core IB stack (rdma-cm module, ib address
resolution
Woodruff, Robert J wrote:
Sujal wrote,
[Sujal] It was disclosed at the BOD meeting that there is no defined
process for inclusion of new features in OFED releases, rather it is
based on discussions and consensus that happen in EWG meetings. This
was the basis for acceptance of the modification
Sujal wrote,
>[Sujal] It was disclosed at the BOD meeting that there is no defined
>process for inclusion of new features in OFED releases, rather it is
>based on discussions and consensus that happen in EWG meetings. This
>was the basis for acceptance of the modifications to the motion at BOD
>a
Please see come comments below marked as [Sujal] related to the
acceptance of motions related to RoCEE at the BOD meeting:
-Original Message-
From: ewg-boun...@lists.openfabrics.org
[mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Woodruff, Robert
J
Sent: Thursday, November 19, 2009
> Having lots of testing exposure can help in validating that all the
> edge cases are handled..
To some extent -- but there also needs to be some thinking involved to
make sure that the interface can actually handle future cases.
> Are there a set of cases that you have in mind ?
For exampl
I am worried that no one has thought through all the issues and corner
cases around address resolution, multicast, etc, and that when we do get
a standardized version of IBoE, we'll have to break core APIs yet again.
Having lots of testing exposure can help in validating that all the edge
ca
> How can 1500 lines out of 240k lines be a big change.. do I have these
> numbers right - is the
> big change you are referring too?
If there are significant changes to the core APIs -- and IBoE has
exactly this impact -- then yes it can be a big change even if the line
count is small.
> Wh
34 matches
Mail list logo
