From: Vakul Garg <vakul.garg@nxp.com>
To: Boris Pismenny <borisp@mellanox.com>,
Aviad Yehezkel <aviadye@mellanox.com>,
"davejwatson@fb.com" <davejwatson@fb.com>,
"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Eran Ben Elisha <eranbe@mellanox.com>
Subject: RE: [PATCH net 2/4] tls: Fix write space handling
Date: Tue, 12 Mar 2019 06:02:20 +0000 [thread overview]
Message-ID: <DB7PR04MB42527C56612F3197CFED2F0A8B490@DB7PR04MB4252.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <c38ba564-bb1e-13cb-e91f-ddd29527dc61@mellanox.com>
> -----Original Message-----
> From: Boris Pismenny <borisp@mellanox.com>
> Sent: Monday, March 11, 2019 9:29 PM
> To: Vakul Garg <vakul.garg@nxp.com>; Aviad Yehezkel
> <aviadye@mellanox.com>; davejwatson@fb.com;
> john.fastabend@gmail.com; daniel@iogearbox.net; netdev@vger.kernel.org
> Cc: Eran Ben Elisha <eranbe@mellanox.com>
> Subject: Re: [PATCH net 2/4] tls: Fix write space handling
>
> >>>> a/net/tls/tls_main.c b/net/tls/tls_main.c index
> >>>> 7e05af75536d..11c1980a75cb 100644
> >>>> --- a/net/tls/tls_main.c
> >>>> +++ b/net/tls/tls_main.c
> >>>> @@ -212,7 +212,7 @@ int tls_push_partial_record(struct sock *sk,
> >>>> struct tls_context *ctx,
> >>>> static void tls_write_space(struct sock *sk)
> >>>> {
> >>>> struct tls_context *ctx = tls_get_ctx(sk);
> >>>> - struct tls_sw_context_tx *tx_ctx = tls_sw_ctx_tx(ctx);
> >>>> + int rc;
> >>>>
> >>>> /* If in_tcp_sendpages call lower protocol write space handler
> >>>> * to ensure we wake up any waiting operations there. For
> >>>> example @@ -223,14 +223,15 @@ static void tls_write_space(struct
> sock *sk)
> >>>> return;
> >>>> }
> >>>>
> >>>> - /* Schedule the transmission if tx list is ready */
> >>>> - if (is_tx_ready(tx_ctx) && !sk->sk_write_pending) {
> >>>> - /* Schedule the transmission */
> >>>> - if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx-
> >>>>> tx_bitmask))
> >>>> - schedule_delayed_work(&tx_ctx->tx_work.work, 0);
> >>>> - }
> >>>> +#ifdef CONFIG_TLS_DEVICE
> >>>> + if (ctx->tx_conf == TLS_HW)
> >>>> + rc = tls_device_write_space(sk, ctx);
> >>>> + else
> >>>> +#endif
> >>>> + rc = tls_sw_write_space(sk, ctx);
> >>>>
> >>>> - ctx->sk_write_space(sk);
> >>>> + if (!rc)
> >>>
> >>> Why do we need to check 'rc'?
> >>>
> >>> If it is required, then ' ctx->sk_write_space(sk)' can move to
> >>> tls_device_write_space() since tls_sw_write_space() always returns '0'.
> >>>
> >>
> >> It is not necessary in the software code path due to the delayed work
> >> that is there. But, we need in the device flow. I'll move it there.
> >>
> >
> > Removal of ctx->sk_write_space(sk) has broken software code flow.
> > The ktls send stops and user space application waits infinitely.
> > When tls_write_space() gets invoked tcp has been able to transmit some
> data.
> > Shouldn't we unconditionally call ctx->sk_write_space() in order to
> > inform user space application about availability of buffer space?
> >
> > Please advise. I would submit the patch.
>
> AFAIU, the code in the software path calls ctx->sk_write_space in its
> schedule work which eventually calls tls_push_sg. Since this flow is
> asynchronous, I thought it was best to postpone the notification and let the
> work handle it.
>
As per my code reading, sk->sk_write_space() is called from tcp code itself after
transmitting socket data.
sk->sk_write_space() is mapped to tls_write_space() which then internally calls
tls_sw_write_space() or tls_device_write_space(). Inside tls_sw_write_space(),
we may not schedule delayed work, but still we need to inform user space about
availability of buffer space by way for invoking of ctx->sk_write_space().
On the other hand, calling ctx->sk_write_space() from tls_push_sg() seems superfluous
& should be removed. For both device and software flows, ctx->sk_write_space() should
be invoked like before from tls_write_space().
> >
> >>
> >>>> + ctx->sk_write_space(sk);
> >>>> }
> >>>>
next prev parent reply other threads:[~2019-03-12 6:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-26 12:12 [PATCH net 0/4] tls: Fix issues in tls_device Boris Pismenny
2019-02-26 12:12 ` [PATCH net 1/4] tls: Fix tls_device handling of partial records Boris Pismenny
2019-02-26 14:57 ` Vakul Garg
2019-02-26 15:05 ` Boris Pismenny
2019-02-26 12:12 ` [PATCH net 2/4] tls: Fix write space handling Boris Pismenny
2019-02-26 12:49 ` Vakul Garg
2019-02-26 14:13 ` Boris Pismenny
2019-03-11 15:06 ` Vakul Garg
2019-03-11 15:59 ` Boris Pismenny
2019-03-12 6:02 ` Vakul Garg [this message]
2019-02-26 12:12 ` [PATCH net 3/4] tls: Fix mixing between async capable and async Boris Pismenny
2019-02-26 12:38 ` Vakul Garg
2019-02-26 13:43 ` Boris Pismenny
2019-02-26 12:12 ` [PATCH net 4/4] tls: Fix tls_device receive Boris Pismenny
2019-02-26 15:01 ` Vakul Garg
2019-02-26 20:34 ` Dave Watson
2019-02-27 3:08 ` Vakul Garg
2019-02-27 15:23 ` Boris Pismenny
2019-02-27 16:28 ` Vakul Garg
2019-02-27 15:26 ` Boris Pismenny
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=DB7PR04MB42527C56612F3197CFED2F0A8B490@DB7PR04MB4252.eurprd04.prod.outlook.com \
--to=vakul.garg@nxp.com \
--cc=aviadye@mellanox.com \
--cc=borisp@mellanox.com \
--cc=daniel@iogearbox.net \
--cc=davejwatson@fb.com \
--cc=eranbe@mellanox.com \
--cc=john.fastabend@gmail.com \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).