[Open-FCoE] [RFC PATCH v2 0/8] adding support to FCoE transport

Bhanu Gollapudi bprakash at broadcom.com
Thu Jan 13 00:56:06 UTC 2011


On Wed, 2011-01-12 at 16:43 -0800, Zou, Yi wrote:
> > >
> > > On Tue, 2011-01-11 at 13:07 -0800, Bhanu Gollapudi wrote:
> > > > On Tue, 2011-01-11 at 11:55 -0800, Zou, Yi wrote:
> > > > > > On Fri, 2011-01-07 at 17:33 -0800, Bhanu Gollapudi wrote:
> > > > > > > On Fri, 2011-01-07 at 09:42 -0800, Yi Zou wrote:
> > > > > > > > This is the RFC v2 of adding fcoe transport to support vendor
> > > > > > specific FCoE
> > > > > > > > transport into the existing Open-FCoE framework.
> > > > > > > >
> > > > > > > > v1:
> > > > > > > > Initial post for adding fcoe transport:
> > > > > > > > https://lists.open-fcoe.org/pipermail/devel/2010-
> > > December/010865.html
> > > > > > > > Follow-up comments & discussions:
> > > > > > > > https://lists.open-fcoe.org/pipermail/devel/2011-
> > > January/010890.html
> > > > > > > >
> > > > > > > > v2:
> > > > > > > > 1. Per Joe's comment, renamed the libfcoe_fip.c to be
> > > fcoe_ctlr.c. I
> > > > > > > > also renamed the new ibfcoe_transport.c to be
> > fcoe_transport.c.
> > > > > > > > 2. Per Bhanu's comment, I have merged the three follow-up
> > > patches
> > > > > > > > from Bhanu with the following changes in fcoe_parse_buffer():
> > > > > > > > a) Though not a problem of the existing fcoe-util since the
> > > sysfs
> > > > > > > > entry is changing to libfcoe anyway, I still want to fill the
> > > buffer
> > > > > > > > of drv_name with default "fcoe" so default behavior is still
> > > the same
> > > > > > > > w/o changing cfg-ethx.
> > > > > > > > b) Fixed the '\n' ending in the input buffer in
> > > fcoe_parse_buffer, we
> > > > > > still
> > > > > > > > need that proper formatting logic from the original
> > > > > > fcoe_if_to_netdev(),
> > > > > > > > otherwise the ifname and drv_name will be messed up, causing
> > > the
> > > > > > lookup for
> > > > > > > > netdev and transport to fail.
> > > > > > > >
> > > > > > > > Testing Notes:
> > > > > > > > Did the checkpatch and tested w/ overnight stress FCoE
> > traffic
> > > on 2
> > > > > > LUNs using
> > > > > > > > fcoe.ko as the default fcoe transport, that seems to be
> > working
> > > ok.
> > > > > > However,
> > > > > > > > loop create/destroy testing is needed before this gets
> > > committed
> > > > > > eventually.
> > > > > > >
> > > > > > > Thanks Yi. bnx2fc patches got installed cleanly on top of your
> > > patches,
> > > > > > > and we were able run FCoE IO traffic, and will leave it running
> > > for the
> > > > > > > weekend.
> > > > > >
> > > > > > Just to confirm IO stress tests over the weekend were successful.
> > > I
> > > > > > submitted a couple of follow-up patches w.r.t ERESTARTSYS.
> > > > > >
> > > > > > Thanks,
> > > > > > Bhanu
> > > > > >
> > > > > The follow-up patches look good to me, I'll pull your 1/3 and 2/3
> > in
> > > and
> > > > > add them to the bottom of the original series, and do some more
> > > testing on
> > > > > loop create/destroy, I only have fcoe as the default transport,
> > it'll
> > > be
> > > > > good if you can run the same test for both fcoe.ko as well as your
> > > bnx2fc
> > > > > at the same time.
> > > > >
> > > > > Thanks,
> > > > > yi
> > > >
> > > > Sure. I'll report the test results tomorrow.
> > >
> > > Yi, I was able to test both bnx2fc and fcoe on our adapter and tests
> > ran
> > > fine overnight. I think these patches are good to go.
> > >
> > > Thanks,
> > > Bhanu
> > >
> >
> //Ignore the previous empty message please, wrong click of the button...
>  
> I am about to be done testing on my side, will send out the finalized
> series shortly. On the user side patch, can you guys split the previous
> user patch into two, where the first addresses this new change, and
> the other would go with your bnx2fc kernel patches to enable bnx2fc for
> fcoe-utils, that would make things cleaner.
> 
> Thanks,
> yi

Sure. will submit shortly.

Thanks.

> 
> 






More information about the devel mailing list