On Wed, Jun 14, 2017 at 10:47 AM, Robert LeBlanc <robert@xxxxxxxxxxxxx> wrote: > On Wed, Jun 14, 2017 at 3:20 AM, Rangankar, Manish > <Manish.Rangankar@xxxxxxxxxx> wrote: >> >> On 13/06/17 10:19 PM, "Robert LeBlanc" <robert@xxxxxxxxxxxxx> wrote: >> >>>On Wed, Jun 7, 2017 at 12:30 PM, Robert LeBlanc <robert@xxxxxxxxxxxxx> >>>wrote: >>>> On Wed, Jun 7, 2017 at 10:28 AM, Chris Leech <cleech@xxxxxxxxxx> wrote: >>>>> On Tue, Jun 06, 2017 at 12:07:10PM -0600, Robert LeBlanc wrote: >>>>>> This patchset enables iSCSI offload drivers to have access to the >>>>>>iface >>>>>> information provided by iscsid. This allows users to have more control >>>>>> of how the driver connects to the iSCSI target. iSER is updated to use >>>>>> iface.ipaddress to set the source IP address if configured. This >>>>>>allows >>>>>> iSER to use multiple ports on the same network or in more complicated >>>>>> routed configurations. >>>>>> >>>>>> Since there is already a change to the function parameters, dst_addr >>>>>> is upgraded to sockaddr_storage so that it is more future proof and >>>>>>makes >>>>>> the size of the struct static and not dependent on checking the >>>>>>SA_FAMILY. >>>>>> >>>>>> This is dependent on updates to Open-iSCSI. >>>>> >>>>> Hi Robert, >>>>> >>>>> I don't think that passing the iface_rec structure directly from the >>>>> iscsid internals into a netlink message is a good way to go about this. >>>>> It's really big, there's an embedded list_head with user address >>>>> pointers that needs to be left out, and there are 32/64-bit layout >>>>> differences. >>>>> >>>>> Let me take a look at how you're proposing using this info for iSER, if >>>>> it makes sense I think we should come up with a better designed >>>>> structure for passing the information. >>>>> >>>>> Thanks, >>>>> Chris >>>>> >>>> >>>> Chris, >>>> >>>> Thank you for your feedback. I agree that the entire iface is probably >>>> overkill, it was more of a proof of concept. We are only using the >>>> ipaddress in the iface for iSER (in my patch), but I could see other >>>> drivers benefiting from some of the other data in the iface (mac, >>>> interface_name, vlan, etc) so I didn't want to be too restrictive so >>>> that it wouldn't have to be extended later. I've not worked on >>>> userspace/kernel interaction before so I need some guidance to make >>>> the transition between userspace and kernel versions smoother. >>>> >>>> This patchset works for what we need and it is very important for us >>>> (and I'm sure others once the feature is available) and I'm happy to >>>> put in the time to get it accepted upstream, I'm just new to kernel >>>> development and need some guidance. >>> >>>Are there other comments/ideas/suggestions specifically from the >>>iSCSI/iSER guys? I'd like to keep this patch moving. >> >> Considering partial iSCSI offload solution (like bnx2i and qedi) point of >> view, we liked the idea from Hannes to create TAP interface to associate >> with each iSCSI offload interface, which will allow us to use userspace >> tools for configuration. I haven't dig into its details yet, but at higher >> level it looks like this will help us to move away from our dependency >> over iscsiuio. > > I'm having a hard time wrapping my head around this idea. How can > configuring a TAP (separate Ethernet device) affect the offload NIC. I > don't see how you can bind to the right interface with the IP address > or how that is passed to rdma_connect() using a TAP. Is TAP used > instead of netlink for communicating between userspace and the kernel? > Obviously by my questions, at the moment I'm not sure how to approach > this at all and would be the wrong person to make this happen. > > If someone can explain how this would work and point to some code that > does something like this (examples are good for me), I can try to > create a patch with TAPs. As I mentioned before, this is important for > us and I'm willing to put in the time to learn and code, but I'm > really lost at this point. > > Thank you, > > ---------------- > Robert LeBlanc > PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 Can we get some more discussion/enlightenment on this? It would be really nice to have this in 4.14 and time is getting short. Thanks. ---------------- Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
