[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A034C2A.50107@cs.wisc.edu>
Date: Thu, 07 May 2009 16:01:30 -0500
From: Mike Christie <michaelc@...wisc.edu>
To: Michael Chan <mchan@...adcom.com>
CC: "open-iscsi@...glegroups.com" <open-iscsi@...glegroups.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"James.Bottomley@...senPartnership.com"
<James.Bottomley@...senPartnership.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
Karen Xie <kxie@...lsio.com>,
Jayamohan Kalickal <jayamohank@...verengines.com>
Subject: Re: [PATCH 4/4] bnx2i: Add bnx2i iSCSI driver.
Michael Chan wrote:
> On Wed, 2009-05-06 at 09:48 -0700, Mike Christie wrote:
>>> +
>>> +/**
>>> + * bnx2i_nl_mesg_recv -
>>> + * @buf: pointer to buffer containing vendor specific message
>>> + * @buf: buffer length
>>> + *
>>> + */
>>> +static int bnx2i_nl_mesg_recv(struct Scsi_Host *shost, uint16_t priv_op,
>>> + int status, char *buf, int buflen)
>>> +{
>>> + struct bnx2i_hba *hba = iscsi_host_priv(shost);
>>> +
>>> + switch (priv_op) {
>>> + case NX2_UIO_UEVENT_NEIGH_LOOKUP:
>>> + default:
>>> + /* handle by cnic driver */
>>> + hba->cnic->nl_priv_msg_recv(hba->cnic, priv_op, buf, buflen);
>>> + break;
>>> + }
>>> +
>>> + return buflen;
>>> +}
>> I think I was wrong with one of the comments I gave you.
>>
>> It seems like we have two iscsi net config models.
>>
>> 1. qla4xxx and Server Engines type of setup where the driver just tells
>> the card to use some ip or do dhcp and some other net settings and it
>> does all the net magic. The iscsi driver does not have to worry about
>> anything like the dhcp process or arp. It only passes down the setup values.
>>
>> 2. cxgb3i and bnx2i type of model where kernel or userspace code is
>> needed to execute many net operations.
>> - Right now, cxgb3i sort of cheated :) and only supports static IPs. It
>> currently uses the iscsi set param interface to do this.
>>
>> - bnx2i wants to add more complicated features and is going to do them
>> in userspace. It us using the private messages that were added in the
>> previous patch.
>>
>>
>> I think cxgb3i is one day going to want to support the same features
>> bnx2i does. If that is right, then should we just make the NX2_UIO
>> events common iscsi events, and hook cxb3i in? It would not use the
>> iscsi set param interface at all and would work just like bnx2i. Is that
>> possible? What about future drivers? Are done making iscsi cards and
>> drivers. If so, thank goodness :) If not then maybe we want to consider
>> some future driver using the #2 module and possibly using this.
>>
>> If cxgb3i is really only going to support static ip setup and we think
>> that bnx2i is going to be unique on how it sets up the network then I
>> NX2_UIO private events are fine. Or is this a case of we are thinking
>> that iscsi hardware people are creating crazy interfaces so there is no
>> why to predict what they are going to do so there is no point in trying
>> to design for them.
>
> If there is any possibility that cxgb3i will use something similar to
> bnx2i, I think we can change the message to a standard one and make the
> message structure somewhat more generic. We'll probably still need a
> private area in the message for hardware or vendor specific information.
>
Ok sounds good to me.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists