From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 01/23] zfcp: make DIX experimental, disabled, and independent of DIF
Date: Thu, 29 Nov 2018 01:40:17 +0000 [thread overview]
Message-ID: <yq1mups1x1a.fsf@oracle.com> (raw)
In-Reply-To: <1a304f10-3603-882a-207a-7618846af746@linux.ibm.com>
Steffen,
As I said, I don't have a problem with having module parameters.
> There's one more important thing that has performance impact: We need to
> pack payload and protection data into the same queue of limited
> length. So for the worst case with DIX, we have to use half the size for
> sg_tablesize to get the other half for sg_prot_tablesize.
Interesting. With the exception of NVMe over PCIe, it's kind of unusual
for modern controllers to have real limits in this area.
> This limits the maximum I/O request size and thus throughput. Using
> read_verify and write_generate does not change the tablesizes, as zfcp
> would still announce support for DIF and DIX. With the new zfcp.dif=1
> and zfcp.dix=0, we can use the full sg_tablesize for payload data and
> sg_prot_tablesize=0. (The DIF "overhead" on the fibre still exists of
> course.)
>
> Are there other ways for accomplishing this which I'm not aware of?
You can set your shost->sg_prot_tablesize. There are pathological corner
cases like dd to the raw block device where you'll suffer if there is
not a 1:1 mapping between data and protection segments. But for regular
I/O where the protection is generated over a whole bio at a time, you
can get away with something smaller.
Anyway. I don't have any problems with you making DIX experimental for
zfcp. Just want to make sure it's done for the right reasons (i.e. not
problems in SCSI or the block layer).
--
Martin K. Petersen Oracle Linux Engineering
parent reply other threads:[~2018-11-29 1:40 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <1a304f10-3603-882a-207a-7618846af746@linux.ibm.com>]
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=yq1mups1x1a.fsf@oracle.com \
--to=martin.petersen@oracle.com \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@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.