: 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
back to a L2 ethernet
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
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 3041 deals
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 any case
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 this
] 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 the big
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 supportable,
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
Richard Frank
facts... the patch set sent from downtown Yoqne'am isn't an addition of feature
turns out that some folks from the Mellanox RD 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
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 involved to
make sure
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] Re: [ofw] SC'09 BOF
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
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 box
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 interface can actually handle future cases
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 interface can actually handle future cases
: [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 interface can actually handle future cases
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
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?
What is the risk area that you are worried about .. do you think it will
break current
transports or existing ULPs ?
If it's just about how the implementation is
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.
What
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
The arguments against including it are:
1.) We have agreed in the EWG to follow a process where code that is to be
included in OFED be
first reviewed and accepted, or at least queued for acceptance in a future
kernel.
So far, since the spec is not yet done, Roland has expressed concerns about
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 example
, 2009 11:31 AM
To: Richard Frank
Cc: o...@lists.openfabrics.org; OpenFabrics EWG
Subject: [ewg] RE: [ofw] SC'09 BOF - Meeting notes
The arguments against including it are:
1.) We have agreed in the EWG to follow a process where code that is to
be included in OFED be
first reviewed and accepted
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
and
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
Richard Frank richard.fr...@oracle.com 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,
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
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
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.
this is
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
30 matches
Mail list logo
