On Thursday, May 31, 2018 at 3:59:44 PM UTC-7, Chris Leech wrote: > > On Tue, May 15, 2018 at 01:25:34PM -0700, The Lee-Man wrote: > > Hi All: > > > > I have been thinking that, with all the new development going on in > Linux > > and in our own open-iscsi community, that a summit would be a good idea. > > > > It turns out both Chris and I live in the Northwest US (near Portland, > OR), > > and it would be easy for us to get together and talk. > > > > But it occurs to me there are a lot of other players in the open-iscsi > > space that might like to get together. > > Oops, actually though I responded to this already. Lee knows I'm up for > some face-to-face discussion, and would be happy to see other people > involved. I'm not sure who's actively watching this list, we might need > to reach out to some of the industry partners with a stake in this > directly. > > > We could have discussions and talks. e.g.: > > > > * recent changes in open-iscsi (e.g. libopeniscsiusr) > > * handling containers > > * booting issues > > * scaling open-iscsi -- thousands of LUNs? > > * network interface: why not use a tap interface? > > * sysfs -- what a mess. How to synchronize with the asynchronous > > * where next? > > > > (I'm sure there are a lot of other topics I can't think of right now) > > This is a good list. A few comments and other ideas. > > > booting issues > > I think booting issues take up more of my time than any other class of > problem. So I'm for looking at rethinking things here. > > iscsistart is a mess, and we could clean it up but ... at one point > someone working on dracut asked why it couldn't just take the kernel > command line and do what was needed. It would avoid having to script a > translation from cmdline to iscsistart (or iscsiadm) commands, and take > control of the booting process more in Open-iSCSI. Maybe not a bad idea? > > > network interface: why not use a tap interface? > > I'm thinking you mean for network configuration support of offloading > HBAs, where iscsiuio is being used with a userspace IP stack. If so, > then putting an encapsulation interface to the drivers in place and > using a tap and the standard IP stack and tools sounds interesting. > > As an additional incentive, iscsiuio currently maps bnx2x and qed > register spaces directly and programs a part of the adapter from > userspace. This actually break with CONFIG_IO_STRICT_DEVMEM and is > something that we should be changing, probably encapsulating ethernet > frames in netlink or something. > > Other big stuff to look at on the kernel side: > > The kernel session locking in general. The frwd_lock/back_lock split was > a pain to figure out the task list corruption problem a while back, and > now it looks like it still might have issues. Reported problems need > looking at sooner, but can we do better with task allocation and > locking? > > Is there something was can do for iscsi_tcp with scsi_mq? I don't know > who proposed it (or how long ago) but it's been stuck in my mind to look > at a limited implementation of MC/S to have multiple TCP connections and > run them as multiple queues per host. Not to compete with dm-multipath, > but only within a single path for performance scale out on the system. > > - Chris > > All excellent ideas/points!
I think the idea is a good one. I also think we might get more feedback from others if we contact them directly, i.e. I will assume some of them would be interested in coming but do not read this list regularly. So the next step would be to come up with a "wish list" of folks that might be interested in joining us, that we could invite. Here's a start: - Mike Christie - Bart van Assche - HCH - Andy Grover - Hannes I should probably also post this idea to the target-devel mailing list. Any other people and/or lists? -- Lee -- 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.
