Re: DCB support for iSCSI
On 12/23/2010 01:23 PM, Rustad, Mark D wrote:
> Shyam,
>
>> -----Original Message-----
>> From: Shyam_Iyer@... [mailto:Shyam_Iyer@...]
>> Sent: Wednesday, December 22, 2010 9:23 PM
>> To: open-iscsi@...
>> Cc: Rustad, Mark D
>> Subject: RE: DCB support for iSCSI
>>
>>> -----Original Message-----
>>> From: open-iscsi@... [mailto:open-
>> iscsi@...]
>>> On Behalf Of Hannes Reinecke
>>> Sent: Monday, December 20, 2010 6:47 AM
>>> To: open-iscsi@...
>>> 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 open-iscsi@...
To unsubscribe from this group, send email to open-iscsi+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RSS Feed