On Wed, Feb 10, 2016 at 11:32:17AM -0800, Lee Duncan wrote: > On 02/01/2016 09:41 AM, Mike Christie wrote: > > On 01/29/2016 04:43 PM, Chris Leech wrote: > >> For some reason, our ISID has only ever had 8-bits of uniqueness. We > >> use the OUI format, which leaves 24-bits of qualifier space that we > >> could be using. > >> > >> This simple change uses the lower 24-bits bits of our 32-bit session id. > >> > >> I've tested this using multiple sessions to a single target portal. > >> Previously ISIDs would start to be reused after 256 connections, causing > >> the target to disconnect existing sessions where there was a collision. > >> With this I can maintain 2048 stable TCP connections to a single target > >> portal. I tried 4096, but something went wrong with 4027 active sessions > >> and I'm not sure where the issue was yet. > >> > > > > Merged. Thanks. > > > > Lee, I see you are fixing the host number rollover issue. When that was > > merged, were you also going to use a ida for the session->sid? We can > > cap the max value at this value. > > > > Yes, I can do that. Good idea. > > To be clear, you're suggesting a cap of 2048, correct?
I don't think we need to be that conservative on the kernel side, it looks like my problem was with iscsiadm and/or iscsid being OOM killed. After hacking around the attr_list growth iscsiadm doesn't get so large, but iscsid still needs quite a bit of RAM to log into many sessions in one command. I can do 4096 if I up the available RAM to my test VM to 4GB. Do we really want to do anything other than limit to the 24-bits that we can place into an ISID? - Chris -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
