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. > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
