From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Keith Busch <kbusch@kernel.org>,
Mark Wunderlich <mark.wunderlich@intel.com>,
Anil Vasudevan <anil.vasudevan@intel.com>,
Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/2] nvme-tcp: set MSG_SENDPAGE_NOTLAST with MSG_MORE when we have more to send
Date: Fri, 8 May 2020 09:35:34 +0200 [thread overview]
Message-ID: <20200508073534.GA682@lst.de> (raw)
In-Reply-To: <ced17f23-0bfc-d076-7c20-ad02c1b54786@grimberg.me>
On Thu, May 07, 2020 at 05:50:38PM -0700, Sagi Grimberg wrote:
>
>>>> What I mean is that nvmet_try_send_data and nvmet_try_send_ddgst may set
>>>> neither MS_MORE nor MSG_EOR. Is that intentional?
>>>
>>> nvmet_try_send_data should set MSG_EOR if it doesn't have more to send
>>> and also nvmet_try_send_ddgst. So its not intentional.
>>
>> Ok. Can you send it with a little helper like I suggested (probably one
>> each for host and target) that ensures the right flags are set
>> everywhere?
>
> I think its actually better without the helper. MSG_SENDPAGE_NOTLAST is
> designed only for sendpage and not for sendmsg which we use for ddgst
> (although the net stack code appears to ignore, but still) and when we
> send a pdu header that has data, we dont need the condition because its
> not last for sure.
>
> So the helpers capture ~60% of the call-sites... seems to me like its
> better off without them at the moment. WDYT?
Ok. Are going to resend with the nvmet_try_send_data fix thrown in?
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-05-08 7:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 5:20 [PATCH 1/2] nvme-tcp: set MSG_SENDPAGE_NOTLAST with MSG_MORE when we have more to send Sagi Grimberg
2020-05-05 5:20 ` [PATCH 2/2] nvmet-tcp: " Sagi Grimberg
2020-05-12 16:13 ` Christoph Hellwig
2020-05-05 6:09 ` [PATCH 1/2] nvme-tcp: " Christoph Hellwig
2020-05-05 6:50 ` Sagi Grimberg
2020-05-05 10:23 ` Christoph Hellwig
2020-05-05 21:53 ` Sagi Grimberg
2020-05-06 4:27 ` Christoph Hellwig
2020-05-08 0:50 ` Sagi Grimberg
2020-05-08 7:35 ` Christoph Hellwig [this message]
2020-05-08 7:38 ` Sagi Grimberg
2020-05-12 16:12 ` Christoph Hellwig
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=20200508073534.GA682@lst.de \
--to=hch@lst.de \
--cc=anil.vasudevan@intel.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mark.wunderlich@intel.com \
--cc=sagi@grimberg.me \
/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.