netdev - Re: [PATCH 4/4] bnx2i: Add bnx2i iSCSI driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 May 2009 10:03:44 -0700
From:	"Michael Chan" <mchan@...adcom.com>
To:	"Mike Christie" <michaelc@...wisc.edu>
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.


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.


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