| Message ID | 20090722232956.26937.24429.stgit@localhost.localdomain |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Wed, 2009-07-22 at 16:29 -0700, Jeff Kirsher wrote: > From: Yi Zou <yi.zou@intel.com> > > Add a define of FCOE_MTU as 2158 bytes and use FCOE_MTU when the LLD is found > to support NETIF_F_FCOE_MTU. The lport->mfs is then calculated out of the > 2158 FCOE_MTU. Otherwise, we stick with the netdev->mtu, i.e., LAN MTU. Also, > change the notification on NETDEV_CHANGEMTU event to bypass changing mfs when > LAN MTU is changed if NETIF_F_FCOE_MTU is supported. > > Signed-off-by: Yi Zou <yi.zou@intel.com> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> > --- Hi Dave, Please don't apply this patch to net-next. The other 4 patches in this series should be fine without it. If this patch is applied to net-next it means that most/all of the other fcoe features (that will go through linux-scsi) become dependent on this patch. I was hoping to push the other fcoe features as-is and then push this patch through linux-scsi after the other 4 patches in this series had been merged by you. Thanks, //Rob -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Robert Love <robert.w.love@intel.com> Date: Thu, 23 Jul 2009 11:27:28 -0700 > Please don't apply this patch to net-next. The other 4 patches in this > series should be fine without it. If this patch is applied to net-next > it means that most/all of the other fcoe features (that will go through > linux-scsi) become dependent on this patch. > > I was hoping to push the other fcoe features as-is and then push this > patch through linux-scsi after the other 4 patches in this series had > been merged by you. Sure, I was just reading over this stuff. But on the other hand, linux-scsi will be dependant upon net-next-2.6 because this patch here uses flags that will only be added there. Therefore there has to be a dependency in one direction or another, the question is which one works better for you FCOE guys. The best thing to do in these situations is usually to create the dependency and merge into the tree where most of the subsystem specific bits (and thus developer ACKs) are needed. And then just occaisionally go and ask the other subsystem guys for ACKs when necessary. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2009-07-23 at 11:40 -0700, David Miller wrote: > From: Robert Love <robert.w.love@intel.com> > Date: Thu, 23 Jul 2009 11:27:28 -0700 > > > Please don't apply this patch to net-next. The other 4 patches in this > > series should be fine without it. If this patch is applied to net-next > > it means that most/all of the other fcoe features (that will go through > > linux-scsi) become dependent on this patch. > > > > I was hoping to push the other fcoe features as-is and then push this > > patch through linux-scsi after the other 4 patches in this series had > > been merged by you. > > Sure, I was just reading over this stuff. > > But on the other hand, linux-scsi will be dependant upon net-next-2.6 > because this patch here uses flags that will only be added there. > Yes, absolutely, but it's only this small patch that creates the dependency. I figured that all of the other fcoe patches could go into James' scsi-misc tree and get merged first. Then this one could go into his scsi-post-merge tree and depend on net-next. It's really up to you and James, I just thought that would be easier. > Therefore there has to be a dependency in one direction or another, > the question is which one works better for you FCOE guys. > > The best thing to do in these situations is usually to create the > dependency and merge into the tree where most of the subsystem > specific bits (and thus developer ACKs) are needed. And then > just occaisionally go and ask the other subsystem guys for ACKs > when necessary. > > _______________________________________________ > devel mailing list > devel@open-fcoe.org > http://www.open-fcoe.org/mailman/listinfo/devel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Robert Love <robert.w.love@intel.com> Date: Thu, 23 Jul 2009 11:48:03 -0700 > Yes, absolutely, but it's only this small patch that creates the > dependency. I figured that all of the other fcoe patches could go into > James' scsi-misc tree and get merged first. Then this one could go into > his scsi-post-merge tree and depend on net-next. > > It's really up to you and James, I just thought that would be easier. So I tried to apply just the networking bits but none of the ixgbe parts apply properly to net-next-2.6, so this patch series will need to be respun and resubmitted in it's entirety so I can apply it properly. It seems that the ixgbe driver now maintains feature flags differently than whatever revision of the driver these patches were generated against. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>Subject: Re: [Open-FCoE] [net-next-2.6 PATCH 5/5] fcoe: Use NETIF_F_FCOE_MTU >flag to set up max frame size (lport->mfs) > >From: Robert Love <robert.w.love@intel.com> >Date: Thu, 23 Jul 2009 11:48:03 -0700 > >> Yes, absolutely, but it's only this small patch that creates the >> dependency. I figured that all of the other fcoe patches could go into >> James' scsi-misc tree and get merged first. Then this one could go into >> his scsi-post-merge tree and depend on net-next. >> >> It's really up to you and James, I just thought that would be easier. > >So I tried to apply just the networking bits but none of the ixgbe >parts apply properly to net-next-2.6, so this patch series will >need to be respun and resubmitted in it's entirety so I can >apply it properly. > >It seems that the ixgbe driver now maintains feature flags differently >than whatever revision of the driver these patches were generated >against. >-- >To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks, I will go back and update these patches to sync w/ the current net-next-2.6. There seem to be patches in net-next-2.6 from net-2.6 after rebasing which were not there at the time these patches were submitted. Thanks, yi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c index 0a5609b..e0a885c 100644 --- a/drivers/scsi/fcoe/fcoe.c +++ b/drivers/scsi/fcoe/fcoe.c @@ -291,8 +291,13 @@ static int fcoe_netdev_config(struct fc_lport *lp, struct net_device *netdev) * user-configured limit. If the MFS is too low, fcoe_link_ok() * will return 0, so do this first. */ - mfs = fc->real_dev->mtu - (sizeof(struct fcoe_hdr) + - sizeof(struct fcoe_crc_eof)); + mfs = fc->real_dev->mtu; + if (fc->phys_dev->features & NETIF_F_FCOE_MTU) { + mfs = FCOE_MTU; + printk(KERN_DEBUG "fcoe:%s supports FCOE_MTU of %d bytes\n", + netdev->name, mfs); + } + mfs -= (sizeof(struct fcoe_hdr) + sizeof(struct fcoe_crc_eof)); if (fc_set_mfs(lp, mfs)) return -EINVAL; @@ -1420,6 +1425,8 @@ static int fcoe_device_notification(struct notifier_block *notifier, case NETDEV_CHANGE: break; case NETDEV_CHANGEMTU: + if (fc->phys_dev->features & NETIF_F_FCOE_MTU) + break; mfs = fc->real_dev->mtu - (sizeof(struct fcoe_hdr) + sizeof(struct fcoe_crc_eof)); diff --git a/drivers/scsi/fcoe/fcoe.h b/drivers/scsi/fcoe/fcoe.h index 0d724fa..be9735d 100644 --- a/drivers/scsi/fcoe/fcoe.h +++ b/drivers/scsi/fcoe/fcoe.h @@ -64,6 +64,10 @@ do { \ printk(KERN_INFO "fcoe: %s" fmt, \ netdev->name, ##args);) +/* Max MTU for FCoE: 14 (FCoE header) + 24 (FC header) + 2112 (max FC payload) + * + 4 (FC CRC) + 4 (FCoE trailer) = 2158 bytes */ +#define FCOE_MTU 2158 + /* * this percpu struct for fcoe */