Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423626AbbEEVtM (ORCPT ); Tue, 5 May 2015 17:49:12 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:8693 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753759AbbEEVtC (ORCPT ); Tue, 5 May 2015 17:49:02 -0400 Message-ID: <55493AC1.9090408@fb.com> Date: Tue, 5 May 2015 15:48:49 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Martin K. Petersen" CC: Jeff Moyer , , , , Subject: Re: [PATCH v2] Support for write stream IDs References: <1430856181-19568-1-git-send-email-axboe@fb.com> <55493097.6040007@fb.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.54.13] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-05_07:2015-05-05,2015-05-05,1970-01-01 signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2575 Lines: 55 On 05/05/2015 03:39 PM, Martin K. Petersen wrote: >>>>>> "Jens" == Jens Axboe writes: > > Jens> The kernel patches deal only with ensuring that the stream > Jens> information gets passed down. If the device requires explicit > Jens> stream open/close actions, then that needs to be handled on the > Jens> side. > > Well, I'm deeply concerned about that "on the side" thing. I know you're > trying to make a shortcut by only caring about the transport mechanism > and deferring the whole programming model piece of the equation. I'm not trying to make a shortcut. I deliberately do not want to make ID generation/assignment part of the kernel. There's no reason that can't exist outside of the kernel, in a libstreamid or similar. In fact I already wrote that for the NVMe bits, it could be extended if other types of devices require open/close type actions for streams. > I think the latter is hugely important, though. And if we defer the > programming model question then the chances are that we'll be stuck with > something lame in the standards. > > The storage vendors appear to think that a handful of stream ids ought > to be enough for anybody. And that IDs are a scarce resource that > they'll hand out for a limited time if you ask nicely. I agree, that's an issue. And I just don't understand why that is. It's not like containerized or virtualized setups are esoteric these days. A handful of IDs might be enough for a single application type setup, but not for anything more elaborate. > I think that model is completely broken and also of limited use for > non-NVM types of storage. Sadly it's the same people who are driving the > NVMe and SCSI proposals so they are similar. It's completely broken for NVM as well. Most people need to farm out the use of such devices, as no single app can drive it to its limit anyways. > My concern is that by adding just enough plumbing to the kernel to allow > the current standards proposals to work then we'll be stuck with them > forever. And I think that would be very unfortunate. The current API doesn't have any real limits (it'll work from 1..MAX_UINT), and the transport part handles 255 streams at the moment. The latter can be easily extended, we can just steal a few more bits. Making it 1023 would be a one liner. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/