From patchwork Thu May 25 18:30:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robert LeBlanc X-Patchwork-Id: 9748899 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9993B601E9 for ; Thu, 25 May 2017 18:30:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 907F227EED for ; Thu, 25 May 2017 18:30:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 82DB82833E; Thu, 25 May 2017 18:30:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8704A27EED for ; Thu, 25 May 2017 18:30:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1036315AbdEYSaD (ORCPT ); Thu, 25 May 2017 14:30:03 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:34017 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030289AbdEYSaC (ORCPT ); Thu, 25 May 2017 14:30:02 -0400 Received: by mail-oi0-f44.google.com with SMTP id b204so290735218oii.1 for ; Thu, 25 May 2017 11:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leblancnet-us.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=l+lmMExoxBRl0IcMKeDhf27JSqodKVuN7a57TvDGcj4=; b=RlTNfENM52iBiK+K1R9XQRJkkfO62DTxVXFqwscmLMPhYzaD+jEXQkP1vO0kfcj3Ie Q8pLuIZp/hAi2ck+1f4DLug1D9Cnb9EdfBVuhBf5C2zzYjtNpVxGH0DG94c2//Bb6yNo 8ar92IeneFYUNLZs/yFmcW3X355MBSwKZvEZuByTdpDGJ3H1ctj/5ARKZSjlRSUhK87I Q9gdCxszjCPFqISk4YduZTDOl898Fndq4LXGrKdjps/XYGThF4x1Kh6pyFglYLmeyeLM JNclsADaA9SrvvQXwrpkbBAAxNru5mmQUBv4KWHO/hIVo5hI/QuJ0JSxF6stTLglJLGu NWeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=l+lmMExoxBRl0IcMKeDhf27JSqodKVuN7a57TvDGcj4=; b=eotxKLMnq/xcbTxQP10vZoaj2LUhkNFOHcgvexrffcfheK+EY/avkLfCHY1c5pAGCB kUyKImQezAHvNGggH5byCsJhC24627VnxqAxgsFkwqZff9LmA6i8MZDD5JG6H1ZwCpsF RQxbJivWT0fhIllGHp/HfuQIoPDqZ2gqrK6VFgUY/YQ4pNnVc3EHxX4AVBS4zJjsKjlt uPQpCPWYZqj7u4gPR5ZDwuKLuulMQDenKhrEIo8gtbQbAkZUz3YOKd+/WdSVh++ex//H +UeAWpC07JMYMQqtrNCYr5zFK+tKk0Rd+0yT6Ek3CgWe6x2L9kVtKK06Lyrl3m/enocS 3ebQ== X-Gm-Message-State: AODbwcCDJRPSgH8aP9ga1jizJ2G5VXduZ2wsPZHAmj/3yc8qMMGegq8M Mk0AUt/EqG2Z62Ti/01NdWJDoSQBaCiI X-Received: by 10.157.37.172 with SMTP id q41mr7542205ota.213.1495737001629; Thu, 25 May 2017 11:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.23.17 with HTTP; Thu, 25 May 2017 11:30:01 -0700 (PDT) X-Originating-IP: [2604:ba00:2:1:78d0:29cb:6b61:b315] From: Robert LeBlanc Date: Thu, 25 May 2017 12:30:01 -0600 Message-ID: Subject: Revisit: [iscsi ifaces / multipathing / etc] thread from 2010 To: linux-rdma , open-iscsi@googlegroups.com Cc: Or Gerlitz , Sagi Grimberg , mchristi@redhat.com Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We have a need to have iSER bind to specific addresses in order to accomplish the multipathing discussing in the previous thread [1]. In inspecting the code, I can pass in a source IP address in the iSER kernel module [2] and the connection happens as expected. I started looking at how to get the source address from the iface I configured and that is where things get messy. I'm looking for some direction and pointers to get something that could be accepted upstream. Userland/kernel integration is something new for me, so I'm trying to learn without asking too many questions. Or Gerlitz pointed me to where the userland tools communicates with the kernel and I _think_ I know how I would have to change the relevant code, but it raises a number of questions. 1. I can't find the iface information in the iscsi_conn_t struct that is passed in ktransport_ep_connect(). I thought that the iface would be tied to a specific connection, but maybe I misunderstand that concept. I would have to extend iscsi_conn_t (or some child struct) to hold the source IP address, but it seems that other technologies may prefer something different, so it seems that the ideal case would to just link the entire iface struct in iscsi_conn_t so that each technology could choose what they like from it. I'm still not sure where the best place would be to link the iface to iscsi_conn_t. 2. The source address would have to be appended to the parameter list passed into ep_connect. If we pass in source_address, that seems simple enough, but if we pass in the iface, the kernel then has to know the iface format. In any case, I'm not sure how to address the change in API. It seems that the iface info could make the cxgb[3,4]i code simpler as it may not have to search for the adapter itself if defined in an iface. 3. Is there some other way I should approach this issue? Thank you. [1] https://groups.google.com/forum/#!topic/open-iscsi/IywifztV7Xs [2] diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c b/drivers/infiniband/ulp/iser/iscsi_iser.c index 5a887ef..e9741df 100644 ---------------- Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 --- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/infiniband/ulp/iser/iscsi_iser.c +++ b/drivers/infiniband/ulp/iser/iscsi_iser.c @@ -59,6 +59,7 @@ #include #include #include +#include #include @@ -814,6 +815,10 @@ static int iscsi_iser_get_ep_param(struct iscsi_endpoint *ep, int err; struct iser_conn *iser_conn; struct iscsi_endpoint *ep; + struct sockaddr_in s_addr; + memset(&s_addr, 0, sizeof(s_addr)); + s_addr.sin_family = AF_INET; + s_addr.sin_addr.s_addr = in_aton("192.168.13.14"); ep = iscsi_create_endpoint(0); if (!ep) @@ -829,7 +834,8 @@ static int iscsi_iser_get_ep_param(struct iscsi_endpoint *ep, iser_conn->ep = ep; iser_conn_init(iser_conn); - err = iser_connect(iser_conn, NULL, dst_addr, non_blocking); + err = iser_connect(iser_conn, (struct sockaddr *) &s_addr, dst_addr, non_blocking); if (err) goto failure; diff --git a/drivers/infiniband/ulp/iser/iser_verbs.c b/drivers/infiniband/ulp/iser/iser_verbs.c index c538a38..6ce1845 100644 --- a/drivers/infiniband/ulp/iser/iser_verbs.c +++ b/drivers/infiniband/ulp/iser/iser_verbs.c @@ -953,6 +953,7 @@ int iser_connect(struct iser_conn *iser_conn, sprintf(iser_conn->name, "%pISp", dst_addr); iser_info("connecting to: %s\n", iser_conn->name); + iser_err("connecting from: %p\n", src_addr); /* the device is known only --after-- address resolution */ ib_conn->device = NULL;