[Open-FCoE] [RFC] Support offload for FCoE

Joe Eykholt jre at nuovasystems.com
Thu Oct 16 00:23:39 UTC 2008


Zou, Yi wrote:
> Hi,
> I am working on offload support for foce and would like to hear
> feedbacks on the approach we are taking for supporting offload in fcoe.
> It touches both current fcoe as well as netdev so I hope to get
> feedbacks on this issue here first before posting to netdev.
> 
> We would like to add a pointer to the net_device structure as something
> like, 
> 
> struct net_device {
> ...
> #if defined(CONFIG_LIBFC) && defined(CONFIG_FCOE)
> struct fcoe_data *fcoe_data;
> #endif
> ...
> };

A minor point, we only need to check CONFIG_FCOE if we're going to
require both, since FCoE implies LIBFC, but no harm as it is.

I wonder if it would be acceptable to use a call through ethtool,
ioctl, or some other interface to get struct fcoe_data from the driver.
We could keep a pointer to fcoe_data in the fcoe_softc if critical, or
refetch it as needed if used infrequently.

Any driver that doesn't know about this would return an error, since you
would use a previously-undefined command code.

That way, you wouldn't require any changes to net_device.  This scales
better as various other offloads are added.

> This is similar to existing member wireless_handler in the net_device
> struct. The struct fcoe_data is the placeholder for any offload
> capabilities LLD wants to provide for fcoe stack to use for offload.
> This can be data related to offload, as well as offload functions that,
> for instance, can match up to current exch_get or exch_put in
> libfc_function_template, or it can have xmit/recv functions if LLD wants
> to bypass the existing fcoe_xmit/fcoe_rcv completely.
> 
> If LLD has fcoe offload capabilities, it will set netdev->fcoe_ops to
> its locally defined fcoe_ops, i.e., netdev->fcoe_ops = &lld_fcoe_ops.
> Otherwise, this ptr will be NULL.
> 
> When fcoe is loaded, in fcoe_create_interface(), it will check LLD's
> support of offload by checking if netdev->fcoe_ops is not NULL. 
> 
> Currently, I have one data member to info the em that allows LLD needs
> to do large receive offload:
> 
> struct fcoe_data {
> 	u16	max_xid_read;
> };
> The max_xid_read is the max exchange id allowed for receive offload via
> direct data placement in a read request where the data received in
> response to read request is placed into scsi data buffer directly,
> instead of doing copy from skb to scsi data buffer. This would also
> require change of the current fc_exch_alloc() function to add the
> flexibility to the exchange manager to allow allocation of exhchange id
> based on the i/o request type, e.g., xid from 1-200 for large receive
> offload. The LLD can then set it up properly by checking the xid upon
> transmitting the SCSI READ cmd to the target. I am working on a patch to
> have fc_exch_alloc() support this.
> 
> On the transmit side, a recent patch has enabled fc_fcp_send_data() to
> send a frame as big as the burst length and let LLD do the segmentation.
> We will need to fix the dev_queue_xmit() path for fcoe if we are to use
> gso for fcoe as tcp/ip does.
> 
> For the offload feature flags, I have already submitted related feature
> flags to netdev for CRC and GSO for fcoe; hopefully they will be
> included later. Adding net_device awareness of foce offload is the next
> step since the offload is built on top of netdev. For any future
> multiple function device, it is anyway going to be outside netdev, so
> it's not a problem.
>  
> I think now it's a good time to discuss what other things are preferred
> to be in the fcoe_data struct or any other thoughts for offload.
> 
> Thanks.
> 
> Yi 
> _______________________________________________
> devel mailing list
> devel at open-fcoe.org
> http://www.open-fcoe.org/mailman/listinfo/devel




More information about the devel mailing list