From: Tadeusz Struk <tadeusz.struk@intel.com> To: James Bottomley <James.Bottomley@HansenPartnership.com>, jarkko.sakkinen@linux.intel.com Cc: flihp@twobit.us, jgg@ziepe.ca, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation Date: Tue, 7 Aug 2018 10:54:56 -0700 [thread overview] Message-ID: <7acd9a7e-4643-001d-a227-e7f80cdbf90f@intel.com> (raw) In-Reply-To: <1533602145.3159.23.camel@HansenPartnership.com> On 08/06/2018 05:35 PM, James Bottomley wrote: > On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote: >> On 08/06/2018 04:05 PM, James Bottomley wrote: >>> For an async interface, shouldn't I be able to queue an >>> arbitrary number of commands without blocking? >> >> That was the approach in the v1 version of this patch, but >> Jason requested this to be changed so that only one command >> at a time can be processed. > > He did? I don't remember that. I think he told you the TPM itself can > only process one operation at once so you didn't need an elaborate > allocation scheme. Right, but the allocation was needed only if more than one command would be queued at a given time. > > But anyway, if you're happy to limit the interface to block after one > command is issued, how is it useful as an asynchronous interface? I > thought the whole argument for the patch was to avoid the producer- > consumer approach which is possible with the current interface and to > use a fully event driven polling interface which can be implemented > single threaded. If you can block in submission, this latter isn't > really possible because your interface isn't really asynchronous. Well it is. This change makes the interface non-blocking and adds a poll interface. Application can submit a command in a non-blocking way, go do something else and get a notification via poll mechanism when the response is ready to consume. We could implement it in a way that more commands can be queued at a time, but in this case there would need to be limit on how many commands can be en-queued. Allowing to send many commands without any limit could be harmful. So what would it be? 10? 50? And what would happen if an application sends 10 commands only to find out the the first has failed? The drive doesn't know about that as it only copies buffers back and forth. There will need to be an interface for the application to rollback all the enqueued commands and stat over. Also what would be the use case for this? TPM is not a crypto accelerator where one submits a batch of buffers for encryption. Usually the sequence of commands requires that subsequent command needs to refer the result from the previous one. For example first command creates a key and the second does something with it passing a handle to the key created in step one. Do you have any particular scenario in mind for multiple commands in-flight? Thanks, -- Tadeusz
WARNING: multiple messages have this Message-ID (diff)
From: tadeusz.struk@intel.com (Tadeusz Struk) To: linux-security-module@vger.kernel.org Subject: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation Date: Tue, 7 Aug 2018 10:54:56 -0700 [thread overview] Message-ID: <7acd9a7e-4643-001d-a227-e7f80cdbf90f@intel.com> (raw) In-Reply-To: <1533602145.3159.23.camel@HansenPartnership.com> On 08/06/2018 05:35 PM, James Bottomley wrote: > On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote: >> On 08/06/2018 04:05 PM, James Bottomley wrote: >>> For an async interface, shouldn't I be able to queue an >>> arbitrary number of commands without blocking? >> >> That was the approach in the v1 version of this patch, but >> Jason requested this to be changed so that only one command >> at a time can be processed. > > He did? I don't remember that. I think he told you the TPM itself can > only process one operation at once so you didn't need an elaborate > allocation scheme. Right, but the allocation was needed only if more than one command would be queued at a given time. > > But anyway, if you're happy to limit the interface to block after one > command is issued, how is it useful as an asynchronous interface? I > thought the whole argument for the patch was to avoid the producer- > consumer approach which is possible with the current interface and to > use a fully event driven polling interface which can be implemented > single threaded. If you can block in submission, this latter isn't > really possible because your interface isn't really asynchronous. Well it is. This change makes the interface non-blocking and adds a poll interface. Application can submit a command in a non-blocking way, go do something else and get a notification via poll mechanism when the response is ready to consume. We could implement it in a way that more commands can be queued at a time, but in this case there would need to be limit on how many commands can be en-queued. Allowing to send many commands without any limit could be harmful. So what would it be? 10? 50? And what would happen if an application sends 10 commands only to find out the the first has failed? The drive doesn't know about that as it only copies buffers back and forth. There will need to be an interface for the application to rollback all the enqueued commands and stat over. Also what would be the use case for this? TPM is not a crypto accelerator where one submits a batch of buffers for encryption. Usually the sequence of commands requires that subsequent command needs to refer the result from the previous one. For example first command creates a key and the second does something with it passing a handle to the key created in step one. Do you have any particular scenario in mind for multiple commands in-flight? Thanks, -- Tadeusz -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-08-07 17:55 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-06 21:09 [PATCH v3 RESEND 0/2] tpm: add support for nonblocking operation Tadeusz Struk 2018-08-06 21:09 ` Tadeusz Struk 2018-08-06 21:14 ` [PATCH v3 RESEND 1/2] tpm: add ptr to the tpm_space struct to file_priv Tadeusz Struk 2018-08-06 21:14 ` Tadeusz Struk 2018-08-06 21:14 ` [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation Tadeusz Struk 2018-08-06 21:14 ` Tadeusz Struk 2018-08-06 23:05 ` James Bottomley 2018-08-06 23:05 ` James Bottomley 2018-08-06 23:05 ` James Bottomley 2018-08-07 0:09 ` Tadeusz Struk 2018-08-07 0:09 ` Tadeusz Struk 2018-08-07 0:35 ` James Bottomley 2018-08-07 0:35 ` James Bottomley 2018-08-07 17:54 ` Tadeusz Struk [this message] 2018-08-07 17:54 ` Tadeusz Struk 2018-08-07 18:20 ` Jason Gunthorpe 2018-08-07 18:20 ` Jason Gunthorpe 2018-08-07 18:20 ` Jason Gunthorpe 2018-08-07 19:09 ` Tadeusz Struk 2018-08-07 19:09 ` Tadeusz Struk
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=7acd9a7e-4643-001d-a227-e7f80cdbf90f@intel.com \ --to=tadeusz.struk@intel.com \ --cc=James.Bottomley@HansenPartnership.com \ --cc=flihp@twobit.us \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=jgg@ziepe.ca \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ /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: linkBe 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.