All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <mchristi@redhat.com>
To: target-devel@vger.kernel.org
Subject: Re: [PATCH v3] target: add emulate_pr backstore attr to toggle PR support
Date: Thu, 28 Jun 2018 19:34:38 +0000	[thread overview]
Message-ID: <5B35384E.7030001@redhat.com> (raw)
In-Reply-To: <20180625185658.31141-1-ddiss@suse.de>

On 06/28/2018 09:48 AM, David Disseldorp wrote:
> On Wed, 27 Jun 2018 13:22:27 -0500, Mike Christie wrote:
> 
>>> So I'd like to propose the following:
>>> 1) Have an attribute to switch between normal mode (pr_support active)
>>>    and new mode (pr_support inactive).
>>> Whether this is done via the existing pr_support attribute or via
>>>    a new attribute is a question of flavor.
>>> 2) If pr_support is inactive, spc_parse_cdb() would reject PR CDBs
>>>    while passthrough_parse_cdb() would pass through those CDBs to
>>>    userspace.
>>> 3) In the "pr_support inactive" mode for devices using
>>> passthrough_parse_cdb() the transport_flag
>>> TRANSPORT_FLAG_PASSTHROUGH_PGR would be set. For devices using
>>>    spc_parse_cdb() a new flag like TRANSPORT_FLAG_REJECT_PGR should be
>>>    used. (See details below regarding dev specific transport_flags.)  
>>
>> I am not sure I got this. How do apps like targetcli that manage tcmu
>> with rtslib tell the tcmu userspace daemon if it should reject PGRs? I
>> think you need 2 device attributes or 1 with a 3rd state:
>>
>> 1. emulate_pr - Controls whether PGRs are executed or failed. Does not
>> matter if in kernel or userspace.
>> 2. pgr_support - Controls if PGRs are executed in the LIO PGR layer in
>> kernel or passed to the backend driver (up to userspace for tcmu or to
>> the physical device for pscsi).
>>
>> So with tcmu and {emulate_pr=0 pgr_support=0} would be pass to userspace
>> and fail PGRs.
> 
> So how should we proceed here? Separate emulate_pr and pgr_support
> interfaces would imply that this change could go in as-is, while a
> multi-state interface would probably require more thought.
> 

I think separate is going to be easier. There is a bug in the
pgr/alua_support files that is going to add a complication we probably
want to limit to that file. The problem is that:

pgr/alua_support=0 means always pass pgr/alua commands to the backend
and do not allow configfs support for operations related to those commands.

For *_support=1 it is mess.

pgr_support = 1 means allow configfs pgr operations and execute pgr
commands in the LIO pgr layer.

alua_support = 1 means allow configfs operations like pgr_support=1
However, for tcmu it means pass alua commands to userspace but for
backends like iblock/file it means execute alua commands in the LIO alua
layer.

We can fix the TRANSPORT_FLAG_PASSTHROUGH_* bits in the kernel so the
names match the behavior they support in the kernel. The problem with
the configfs files is that they are exported to apps already.

If we do multiple files then emulate_pr is very clear what is meant
across all backends and works like other device attributes.

  parent reply	other threads:[~2018-06-28 19:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-25 18:56 [PATCH v3] target: add emulate_pr backstore attr to toggle PR support David Disseldorp
2018-06-26 12:35 ` Bodo Stroesser
2018-06-27 18:22 ` Mike Christie
2018-06-27 22:05 ` David Disseldorp
2018-06-28 14:48 ` David Disseldorp
2018-06-28 19:34 ` Mike Christie [this message]
2018-10-30 14:07 ` David Disseldorp

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=5B35384E.7030001@redhat.com \
    --to=mchristi@redhat.com \
    --cc=target-devel@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: 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.