> > > > 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 -- 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
