RE: DCB support for iSCSI
> -Original Message- > From: Mike Christie [mailto:micha...@cs.wisc.edu] > Sent: Monday, January 03, 2011 3:39 PM > To: open-iscsi@googlegroups.com > Cc: Iyer, Shyam; mark.d.rus...@intel.com > Subject: Re: DCB support for iSCSI > > On 12/22/2010 11:22 PM, shyam_i...@dell.com wrote: > >> 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. > > > > So, in the iSCSI case the well known port number 3260 becomes the > priority decider. > > > > I actually broke the code to support ports other than 3260 in a rhel > test release, and so I know people use other ports in real life setups > :) I would bet the vast majority of times it is 3260, but it is not > always so I do not think you can count on it if that is what you are > saying. > The spec tries to make it easy by assigning a priority tag based on the application's well known port number. As long as the lldp peers know what port number to use for priority tagging it should be fine. > > > 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. > > > > What is ETS? Sorry for the acronym.. It means enhanced transmission selection. This link is pretty good.. http://www.ieee802.org/1/files/public/docs2008/az-wadekar-ets-proposal-0608-v1.01.pdf -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RE: DCB support for iSCSI
Mike, > -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Mike Christie > Sent: Monday, January 03, 2011 12:48 PM > To: open-iscsi@googlegroups.com > Cc: Rustad, Mark D; shyam_i...@dell.com > Subject: Re: DCB support for 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. I don't know myself if it could be a "need" or if it only might be a "want". > 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? Yes. At least that seemed like the most potentially valuable way to use the priority mask returned from lldpad. Of course if the returned mask only has a single bit, then there is no opportunity to further distinguish priorities. When multiple bits are returned, then additional information available to iscsid could be used to control that. In my initial work I believe that I will ignore this possibility and simply set the highest priority indicated in the mask, but know that the opportunity exists for more specific control by coordinating the DCB application priority assignment with some iscsi configuration. When the additional work is done, I would suggest that the iscsi priorities used in this context simply be an offset into the mask. That is, 1 would be the highest in the mask, 2 the next-to-highest and so forth. That way, the DCB configuration could change and iscsid would still do something sensible. -- Mark Rustad, mark.d.rus...@intel.com -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: DCB support for iSCSI
On 12/23/2010 01:35 PM, Rustad, Mark D wrote: Mike, -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Tuesday, December 21, 2010 6:54 PM To: open-iscsi@googlegroups.com Cc: Rustad, Mark D Subject: Re: DCB support for iSCSI Does you guys know what is up with iscsi offload? Have you guys talked to them? For something like be2iscsi it seems like it would be done all in hardware/firmware so like the emulex fcoe driver, lpfc, it would not use lldpad. But maybe some of the iscsi offload cards that do a lot in software and do more of direct data placement type of offload, how would that work? I really don't know anything about the offload solutions. It seems to me that if DCB, FCoE and iSCSI are all off-loaded, then it is all a matter of how that particular product is configured. Perhaps a more interesting case would be a product that offloads DCB and FCoE, but not iSCSI. Then iSCSI would have to get information out of the offloaded DCB solution. Hmmm. Could lldpad become a client of such a solution to provide the same information to other applications? That seems to me like the best place to deal with it if that is possible. Ok agree. So not my problem :) -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: DCB support for iSCSI
On 12/17/2010 11:55 AM, 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. Either one is ok with me. But I think #1 is going to be easier for boot as you mention. To support fcoe boot now, distros throw lldpad in the intramfs/initrds already, right? So I guess this would make support iscsi dcb easier as there is not much new stuff to do. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: DCB support for iSCSI
On 12/23/2010 01:23 PM, Rustad, Mark D wrote: Shyam, -Original Message- From: shyam_i...@dell.com [mailto:shyam_i...@dell.com] Sent: Wednesday, December 22, 2010 9:23 PM To: open-iscsi@googlegroups.com Cc: Rustad, Mark D Subject: RE: DCB support for iSCSI -Original Message- From: open-iscsi@googlegroups.com [mailto:open- is...@googlegroups.com] On Behalf Of Hannes Reinecke Sent: Monday, December 20, 2010 6:47 AM To: open-iscsi@googlegroups.com 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,inter
Re: DCB support for iSCSI
On 12/22/2010 11:22 PM, shyam_i...@dell.com wrote: 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. So, in the iSCSI case the well known port number 3260 becomes the priority decider. I actually broke the code to support ports other than 3260 in a rhel test release, and so I know people use other ports in real life setups :) I would bet the vast majority of times it is 3260, but it is not always so I do not think you can count on it if that is what you are saying. 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. What is ETS? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RE: DCB support for iSCSI
Mike, > -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Mike Christie > Sent: Tuesday, December 21, 2010 6:54 PM > To: open-iscsi@googlegroups.com > Cc: Rustad, Mark D > Subject: Re: DCB support for iSCSI > > Does you guys know what is up with iscsi offload? Have you guys talked > to them? For something like be2iscsi it seems like it would be done all > in hardware/firmware so like the emulex fcoe driver, lpfc, it would not > use lldpad. But maybe some of the iscsi offload cards that do a lot in > software and do more of direct data placement type of offload, how > would > that work? I really don't know anything about the offload solutions. It seems to me that if DCB, FCoE and iSCSI are all off-loaded, then it is all a matter of how that particular product is configured. Perhaps a more interesting case would be a product that offloads DCB and FCoE, but not iSCSI. Then iSCSI would have to get information out of the offloaded DCB solution. Hmmm. Could lldpad become a client of such a solution to provide the same information to other applications? That seems to me like the best place to deal with it if that is possible. -- Mark Rustad, mark.d.rus...@intel.com -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RE: DCB support for iSCSI
Shyam, > -Original Message- > From: shyam_i...@dell.com [mailto:shyam_i...@dell.com] > Sent: Wednesday, December 22, 2010 9:23 PM > To: open-iscsi@googlegroups.com > Cc: Rustad, Mark D > Subject: RE: DCB support for iSCSI > > > -Original Message- > > From: open-iscsi@googlegroups.com [mailto:open- > is...@googlegroups.com] > > On Behalf Of Hannes Reinecke > > Sent: Monday, December 20, 2010 6:47 AM > > To: open-iscsi@googlegroups.com > > 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 wha
RE: DCB support for iSCSI
> -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Hannes Reinecke > Sent: Monday, December 20, 2010 6:47 AM > To: open-iscsi@googlegroups.com > 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. So, in the iSCSI case the well known port number 3260 becomes the priority decider. 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. > > > 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. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > h...@suse.de+49 911 74053 688 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Markus Rex, HRB 16746 (AG Nürnberg) > Thanks, Shyam Iyer -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: DCB support for iSCSI
On 12/17/2010 11:55 AM, 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. 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)? iscsistart uses the same code as iscsid, so you only need to change that io.c iscsi_io_tcp_connect call. 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? Does you guys know what is up with iscsi offload? Have you guys talked to them? For something like be2iscsi it seems like it would be done all in hardware/firmware so like the emulex fcoe driver, lpfc, it would not use lldpad. But maybe some of the iscsi offload cards that do a lot in software and do more of direct data placement type of offload, how would that work? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RE: DCB support for iSCSI
> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Monday, December 20, 2010 3:47 AM > To: open-iscsi@googlegroups.com > 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, mark.d.rus...@intel.com -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
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 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. > 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. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
DCB support for iSCSI
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. 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)? 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? -- Mark Rustad, mark.d.rus...@intel.com -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
