> -----Original Message-----
> From: Hannes Reinecke [mailto:[email protected]]
> Sent: Monday, December 20, 2010 3:47 AM
> To: [email protected]
> Cc: Rustad, Mark D
> Subject: Re: DCB support for iSCSI
> 
> On 12/17/2010 06:55 PM, Rustad, Mark D wrote:
> > Hi all,
> >
> > I am looking into adding support for DCB into iSCSI. I think
> > it is best to do this in a way that will not require a strong
> > dependency on DCB for iSCSI. That is, installing open-iscsi
> > should not then require open-lldp to also be installed. I see
> > at least two ways to do this.
> >
> > The first is to have open-lldp supply a library that iscsid
> > can link with at run time (through dlopen/dlsym). In that way,
> > if the library is not there, iscsid can go on as usual. It
> > also allows lldpad more freedom to change over time.
> >
> > The second way is to put a little more code directly in
> > iscsid and have it interrogate lldpad for the proper priority
> > to set. If the lldpad socket isn't there, iscsid can go on as
> > usual. I am thinking that open-lldp can supply the source files
> > that would be placed directly into open-iscsi and updated as
> > needed. These source files might also be used by other network
> > applications that want to participate fully in a DCB environment.
> >
> > I had been leaning toward the first way until I started thinking
> > about iscsistart and initrds. Then it seemed that the run-time
> > linkage would create more trouble than it would be worth.
> > It started to seem like over-engineering.
> >
> I would prefer the second method.
> DCB configuration itself is quite involved and requires to
> negotiate the transfer parameter before the connection is setup.
> And as DCB is in fact quite a different beast from iSCSI we
> should keep it as a separate daemon.
> Which would also be in-line with the current fcoeadm setup.

In both of my approaches the DCB configuration would be done as it is now. The 
only question is how to get the proper priority applied to the sockets being 
used for iscsi traffic. This is about getting that information from lldpad to 
iscsid.

> > In either case, I was thinking about adding code right before
> > the connect() call in iscsi_io_tcp_connect to set the socket
> > options based on information from lldpad. Is anything more
> > than that needed (besides doing something similar in iscsistart)?
> >
> VLAN creation.
> From what I've seen iSCSI support in DCB would work similar
> to FCoE, ie the iSCSI traffic will be sent via a separate
> VLAN. Which we would need to create, eventually.
> So basically we would need something similar to 'fipvlan'
> or integrate this functionality into open-iscsi.

Yes, a VLAN would be the expected setup and that would all have to be done as 
usual.

> > The socket protocol to lldpad is already versioned, so that
> > should prevent any terribly rude surprises in the future should
> > mismatched components be used together.
> >
> > Does this sound reasonable to you? Would you rather see it done
> > in a different way? Would you prefer for iscsid to simply send
> > a file descriptor to the lldpad socket and have lldpad set the
> > socket options itself?
> >
> Ugh. No. As mentioned, I fear we would need to setup a VLAN
> interface here, in which case we would be running off a
> totally different socket anyway.

I am sure that my use of socket has been confusing. There is the UNIX socket 
used to communicate locally with lldpad, which is of course completely separate 
from the iscsi INET sockets managed by iscsid. The last idea I threw out there 
was the possibility of iscsid sending its iscsi sockets to the lldpad socket to 
allow lldpad to set whatever socket options it wants on them. The more typical 
alternative would be for iscsid to query lldpad over lldpad's socket and then 
apply socket options to its iscsi sockets based on information provided by 
lldpad. The socket-passing option could allow the lldpad/kernel networking 
relationship to evolve more independently from other user-space networking 
apps, but is a little obscure and suggests that apps would trust lldpad with 
their sockets.

Anyway, the query to lldpad would provide an indication of what the application 
is (iscsi of course in this case) and the interface name for the session. 
lldpad would respond with the configured priority for that application and 
interface, which would normally happen to be a VLAN interface when DCB is in 
use.

-- 
Mark Rustad, [email protected]


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Reply via email to