All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Meneghini <jmeneghi@redhat.com>
To: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Subject: LSF/MM IO Track Topics - Take 2
Date: Mon, 2 May 2022 12:58:16 -0400	[thread overview]
Message-ID: <3a83feff-e057-e97e-59bb-5570518b95bd@redhat.com> (raw)

We have no lsf/mailman list this year at LSF/MM so please add people to the cc list of this email for any LSF/MM IO Track 
related discussion topics.

One topic I'd like to discuss which I don't see on the IO Track agenda this year is NVMe-oF Discovery Services. I'd like to 
understand what Linux wants to do with all of the Discovery related TPs that are coming out of NVMexpress.org right now.

TP-8010 - Centralized Discovery Controller
TP-8009 - mDNS Discovery
TP-8013 - Unique Dsicovery NQN
TP-8014 - Discovery Controller

When we combine all of these with the security TPs (TP-8006 In Band Authenticate and TP-8011 TLS 1.3 Profile) we start to see 
proposals like the attached picture.

There are additional NVMe-oF proposals coming from FMDS which will impact Discovery and there is even a proposal at IETF for a 
new project for a Distributed NVMe-oF Discovery Server.

https://www.ietf.org/id/draft-nof-requirement-00.html
https://www.ietf.org/id/draft-nof-framework-00.html

IMHO NVMe-oF Discovery is turning into a giant mess. I'd like to talk about this at LSF/MM and understand how Linux plans to 
support the increasingly complex and convoluted landscape of NVMe-oF discovery; especially at it relates to multi-vendor and 
multi-fabric environments that support NVMe/TCP.

See my comments about this at:

http://lists.infradead.org/pipermail/linux-nvme/2022-March/030847.html

/John

On 5/2/22 11:46, Martin K. Petersen wrote:
 >
 > John,
 >
 >> 1. Is there an lsf mailman list this year?
 >
 > We haven't set it up since the attendee list has been a moving target.
 > And most of the things that went out on that list in the past (lunch
 > logistics, evening event announcements, etc.) now comes from the Linux
 > Foundation event management system.
 >
 > Happy to set it up if there's interest.
 >
 >> 2. It looks like the IO track is kind of sparse this year. Are you
 >> still in need of topics for discussion?
 >
 > Sure, while I suspect some topics will take longer than the allotted
 > time, there should be slots available.
 >
On 5/2/22 11:26, John Meneghini wrote:
  > Hi everyone.
  >
  > Unfortunately, I will not be able to attend LSF/MM in person this year but Martin and Omar sent me a virtual invitation so I
  > will be participating virtually over Zoom.
  >
  > A couple of questions:
  >
  > 1. Is there an lsf mailman list this year?
  >
  > I seem to have lost access to my old account so I just subscribed at https://lists.linuxfoundation.org/mailman/subscribe/lsf.
  > If Marin or Hannes can let me in that would be appreciated.
  >
  > 2. It looks like the IO track is kind of sparse this year. Are you still in need of topics for discussion?
  >
  > Please look for me on the Zoom call and/or feel free to call me or text me at any of the links below.

-- 
John Meneghini
jmeneghi@redhat.com
+1-978-930-3519 (cell)
https://t.me/johnmeneghini
https://www.linkedin.com/in/johnmeneghini/



                 reply	other threads:[~2022-05-02 17:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=3a83feff-e057-e97e-59bb-5570518b95bd@redhat.com \
    --to=jmeneghi@redhat.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    /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.