On 12/23/2010 01:23 PM, Rustad, Mark D wrote:
Shyam,
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, December 22, 2010 9:23 PM
To: [email protected]
Cc: Rustad, Mark D
Subject: RE: DCB support for iSCSI
-----Original Message-----
From: [email protected] [mailto:open-
[email protected]]
On Behalf Of Hannes Reinecke
Sent: Monday, December 20, 2010 6: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.
I would also prefer a dcb client like that allows configuring for
iSCSI traffic. I do need an open-lldpad as a library though but that
is to integrate the library with libvirt to keep the architecture clean
and not have libvirt call various exec commands to configure dcb for
VMs.
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.
Well there are more methods actually. Separating them into separate
VLAN's would tag them to the priority of the VLAN(8 in all) however
sometimes the tag is based on the application type port number.
Exactly. That is what I am trying to support by querying lldpad as to what the
priority should be for the application, iscsi in this case.
So, in the iSCSI case the well known port number 3260 becomes the
priority decider.
Except when the system is set up to use a non-standard port. If one could count
on the standard port always being used, this could be handled in the kernel and
be directly controlled by lldpad. At least if all of the iscsi traffic on an
interface should be at the same priority.
Usecase - Tag all iSCSI traffic to a specific port type in a
virtualized environment. Its very cumbersome to manage vlans in the
virtualized environments.
Also ETS determines that within the same priority group the bandwidth
could be split further. Now, this could be per connection. My hunch is
that we need more flexible ways of splitting the bandwidth within a
priority group per connection via the lldpad.
I had been wondering if target address should also be considered in setting the
priority. I had mainly been considering interface and application just because
that seems to be what lldpad knows and cares about. Of course, lldpad returns a
mask of allowed priorities for an application, so iscsid could choose among
those priorities. So it would seem that additional iscsi configuration would be
required to add target address into the priority selection scheme. Is this a
desirable addition to open-iscsi?
So you are thinking that you would have one interface on the initiator
that is connected to 2 targets portals, and the connection to each
target portal would need a different priority? That sounds like
something that would happen.
So would then the iscsi query lldpad with the interface and application
info. Then lldpad sends the priority mask. iscsi then looks up user
specified info (a target address,port,interface to priority map) and
then set the priority?
--
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.
