[ewg] Re: [ofw] SC'09 BOF - Meeting notes

[Liran Liss]

90% of the changes are either in the mlx4 driver, or self-contained in
the rdmaoe flow of the cma, which handles rdmaoe addressing and
connection setup.
The rest of the changes indeed touch various locations of the stack, but
they are either definitions or follow the same logic:

        if (rdma_is_trasnport(ib_device, RDMA_TRANSPORT_RDMAOE))
                do_something_rdmaoe_specific();

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.

As for vlan id and priorities - we are fully aware to the importance of
exposing vlan ids and priorities to the user, but thanks for pointing
this out.
There are deployments today that work fine with the current patches; but
in any case, we are planning to send a follow-up patch set that adds
vlan+priority support in the near future.

--Liran 

-----Original Message-----
From: ewg-bounces at lists.openfabrics.org
[mailto:ewg-bounces at 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 <richard.frank at 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, ib address
resolution module, ib uverbs module and even the mad module) and
ofcourse some of the kernel and user space IB hw specific libraries.

> What is the risk area that you are worried about .. do you think it 
> will break current  transports or existing ULPs?

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 or that module / line, next, what you except the
maintainers to do?

> If it's just about how the implementation is done.. can this be 
> resolved concurrently with getting the bits available for evaluation
now..

an rdmaoe branch at the git tree was set and an releases are maintained,
its all what you need for evaluation, five lines later you're talking on
deployments...

> As RoCEE is totally transparent to existing ULPs.. any potential 
> changes would not be visible.. and therefore not an issue for ULP /
clients going forward.. right?

this is how you see things, since the IBTA IBXoE annex isn't released,
you just don't know what would be the bottom line.

> Oracle would like to see RoCEE get into 1.5

you guys have set a note to the rds developer community that that Oracle
recently moved from 1.3.x to 1.4.y, no special work is expected on 1.5.z
and that you have lots of plans for 1.6.w ... what's the urgency to get
these bits into 1.5?

> We are testing with RoCEE now and plan to deploy it fairly soon.. in 
> very large configuratio

the proposed patch set doesn't let you use non zero VLAN, aren't you
expecting Ethernet customers to trivially require that? also you can't
use non zero traffic class (priority bits), where all the IBXoE
materials are talking about how much working on a lossless traffic class
is a must... if indeed this is the case, the patch set is useless
without the ability to specify a traffic class, as CEE switches would
typically (always?) set only some of the traffic classes to be lossless
(e.g the ones used for FCoE, IBXoE) and the rest to be lossy


Or
_______________________________________________
ewg mailing list
ewg at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg