All of lore.kernel.org
 help / color / mirror / Atom feed
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 2/2] nvme-rdma: Add handling for connecting to IPv6 targets
Date: Tue, 2 Aug 2016 14:51:53 +0200	[thread overview]
Message-ID: <20160802125153.GC13235@lst.de> (raw)
In-Reply-To: <CAG4TOxPNnUKWeh7FUY8YB127sx8yMu41FuP4hxUMCan_HWQmVQ@mail.gmail.com>

On Mon, Aug 01, 2016@09:06:07AM -0700, Roland Dreier wrote:
> On Mon, Aug 1, 2016@8:50 AM, Christoph Hellwig <hch@lst.de> wrote:
> > It'd still need all the scope ID handling similar to what Roland did,
> > and that's a fair chunk of code.  We have a few options to handle the
> > different allowed addresses:
> >
> >  (1) v4/v6 only flags
> >  (2) having low-level v4/v6 handlers and one that tries these both
> >  (3) using the try both handler and rejecting the wrong one after
> >      parsing.
> >
> > (3) seems easiest, but (2) sounds fine to me.  But I'd really like to
> > hear from folks on the netdev list what they think of that idea first.
> 
> I think adding a new helper that parses both v4 and v6 addresses +
> scope ID seems like the best thing for now.  I did a grep for in6_pton
> and it looks like at least fs/cifs/netmisc.c and net/sunrpc/addr.c
> could use the helper.
> 
> What do you think of adding inet_pton_with_scope() to
> net/core/utils.c?  I'm open to better ideas on the name.  But I can
> code that up and use it in nvme, as well as convert over the two
> places I mentioned above.  The first parameter of the function can be
> an af, and the caller can pass in AF_UNSPEC, AF_INET, or AF_INET6 to
> restrict the parsing to one type of address (or not).

Sounds fine to me, and I hope the netdev folks (Cc'ed) are fine with
that as well.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Roland Dreier <roland@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Jens Axboe <axboe@fb.com>,
	linux-nvme@lists.infradead.org,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH 2/2] nvme-rdma: Add handling for connecting to IPv6 targets
Date: Tue, 2 Aug 2016 14:51:53 +0200	[thread overview]
Message-ID: <20160802125153.GC13235@lst.de> (raw)
In-Reply-To: <CAG4TOxPNnUKWeh7FUY8YB127sx8yMu41FuP4hxUMCan_HWQmVQ@mail.gmail.com>

On Mon, Aug 01, 2016 at 09:06:07AM -0700, Roland Dreier wrote:
> On Mon, Aug 1, 2016 at 8:50 AM, Christoph Hellwig <hch@lst.de> wrote:
> > It'd still need all the scope ID handling similar to what Roland did,
> > and that's a fair chunk of code.  We have a few options to handle the
> > different allowed addresses:
> >
> >  (1) v4/v6 only flags
> >  (2) having low-level v4/v6 handlers and one that tries these both
> >  (3) using the try both handler and rejecting the wrong one after
> >      parsing.
> >
> > (3) seems easiest, but (2) sounds fine to me.  But I'd really like to
> > hear from folks on the netdev list what they think of that idea first.
> 
> I think adding a new helper that parses both v4 and v6 addresses +
> scope ID seems like the best thing for now.  I did a grep for in6_pton
> and it looks like at least fs/cifs/netmisc.c and net/sunrpc/addr.c
> could use the helper.
> 
> What do you think of adding inet_pton_with_scope() to
> net/core/utils.c?  I'm open to better ideas on the name.  But I can
> code that up and use it in nvme, as well as convert over the two
> places I mentioned above.  The first parameter of the function can be
> an af, and the caller can pass in AF_UNSPEC, AF_INET, or AF_INET6 to
> restrict the parsing to one type of address (or not).

Sounds fine to me, and I hope the netdev folks (Cc'ed) are fine with
that as well.

  parent reply	other threads:[~2016-08-02 12:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-31  7:27 [PATCH 1/2] nvme-rdma: Don't leak uninitialized memory in connect request private data Roland Dreier
2016-07-31  7:27 ` Roland Dreier
2016-07-31  7:27 ` [PATCH 2/2] nvme-rdma: Add handling for connecting to IPv6 targets Roland Dreier
2016-07-31  7:27   ` Roland Dreier
2016-07-31  8:45   ` Sagi Grimberg
2016-07-31  8:45     ` Sagi Grimberg
2016-07-31 10:58     ` Sagi Grimberg
2016-07-31 10:58       ` Sagi Grimberg
2016-07-31 15:33       ` Roland Dreier
2016-07-31 15:33         ` Roland Dreier
2016-08-01  5:58         ` Sagi Grimberg
2016-08-01  5:58           ` Sagi Grimberg
2016-08-01  6:15           ` Sagi Grimberg
2016-08-01  6:15             ` Sagi Grimberg
2016-08-01 11:09       ` Christoph Hellwig
2016-08-01 11:09         ` Christoph Hellwig
2016-08-01 11:24         ` Sagi Grimberg
2016-08-01 11:24           ` Sagi Grimberg
2016-08-01 15:50           ` Christoph Hellwig
2016-08-01 15:50             ` Christoph Hellwig
2016-08-01 16:06             ` Roland Dreier
2016-08-01 16:06               ` Roland Dreier
2016-08-02  6:43               ` Sagi Grimberg
2016-08-02  6:43                 ` Sagi Grimberg
2016-08-02 12:51               ` Christoph Hellwig [this message]
2016-08-02 12:51                 ` Christoph Hellwig
2016-08-18  7:44               ` Sagi Grimberg
2016-08-18  7:44                 ` Sagi Grimberg
2016-08-22  4:44                 ` Roland Dreier
2016-08-22  4:44                   ` Roland Dreier
2016-08-22  6:47                   ` Sagi Grimberg
2016-08-22  6:47                     ` Sagi Grimberg
2016-08-02  6:41             ` Sagi Grimberg
2016-08-02  6:41               ` Sagi Grimberg
2016-08-01 11:09   ` Christoph Hellwig
2016-08-01 11:09     ` Christoph Hellwig
2016-07-31  8:44 ` [PATCH 1/2] nvme-rdma: Don't leak uninitialized memory in connect request private data Sagi Grimberg
2016-07-31  8:44   ` Sagi Grimberg
2016-08-01 11:07 ` Christoph Hellwig
2016-08-01 11:07   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160802125153.GC13235@lst.de \
    --to=hch@lst.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.