From: Stefano Brivio <sbrivio@redhat.com>
To: Atul Gupta <atul.gupta@chelsio.com>
Cc: davejwatson@fb.com, davem@davemloft.net,
herbert@gondor.apana.org.au, sd@queasysnail.net,
linux-crypto@vger.kernel.org, netdev@vger.kernel.org,
ganeshgr@chelsio.com
Subject: Re: [PATCH v10 crypto 07/11] chtls: Program the TLS Key
Date: Mon, 12 Mar 2018 14:30:14 +0100 [thread overview]
Message-ID: <20180312143014.2cb8a4be@epycfail> (raw)
In-Reply-To: <1520622616-6557-6-git-send-email-atul.gupta@chelsio.com>
On Sat, 10 Mar 2018 00:40:12 +0530
Atul Gupta <atul.gupta@chelsio.com> wrote:
> Initialize the space reserved for storing the TLS keys
> get and free the location where key is stored for the TLS
> connection
> Program the tx and rx key as received from user in
> struct tls12_crypto_info_aes_gcm_128 and understood by hardware.
>
> Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
> ---
> drivers/crypto/chelsio/chtls/chtls_hw.c | 371 ++++++++++++++++++++++++++++++++
> 1 file changed, 371 insertions(+)
> create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c
>
> diff --git a/drivers/crypto/chelsio/chtls/chtls_hw.c b/drivers/crypto/chelsio/chtls/chtls_hw.c
> new file mode 100644
> index 0000000..40cf84f
> --- /dev/null
> +++ b/drivers/crypto/chelsio/chtls/chtls_hw.c
> @@ -0,0 +1,371 @@
> +/*
> + * Copyright (c) 2017 Chelsio Communications, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Written by: Atul Gupta (atul.gupta@chelsio.com)
> + */
> +
> +#include <linux/module.h>
> +#include <linux/list.h>
> +#include <linux/workqueue.h>
> +#include <linux/skbuff.h>
> +#include <linux/timer.h>
> +#include <linux/notifier.h>
> +#include <linux/inetdevice.h>
> +#include <linux/ip.h>
> +#include <linux/tcp.h>
> +#include <linux/tls.h>
> +#include <net/tls.h>
> +
> +#include "chtls.h"
> +#include "chtls_cm.h"
> +
> +static void __set_tcb_field_direct(struct chtls_sock *csk,
> + struct cpl_set_tcb_field *req, u16 word,
> + u64 mask, u64 val, u8 cookie, int no_reply)
> +{
> + struct ulptx_idata *sc;
> +
> + INIT_TP_WR_CPL(req, CPL_SET_TCB_FIELD, csk->tid);
> + req->wr.wr_mid |= htonl(FW_WR_FLOWID_V(csk->tid));
> + req->reply_ctrl = htons(NO_REPLY_V(no_reply) |
> + QUEUENO_V(csk->rss_qid));
> + req->word_cookie = htons(TCB_WORD_V(word) | TCB_COOKIE_V(cookie));
> + req->mask = cpu_to_be64(mask);
> + req->val = cpu_to_be64(val);
> + sc = (struct ulptx_idata *)(req + 1);
> + sc->cmd_more = htonl(ULPTX_CMD_V(ULP_TX_SC_NOOP));
> + sc->len = htonl(0);
> +}
> +
> +static void __set_tcb_field(struct sock *sk, struct sk_buff *skb, u16 word,
> + u64 mask, u64 val, u8 cookie, int no_reply)
> +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> + struct cpl_set_tcb_field *req;
> + struct ulptx_idata *sc;
> + unsigned int wrlen = roundup(sizeof(*req) + sizeof(*sc), 16);
> +
> + req = (struct cpl_set_tcb_field *)__skb_put(skb, wrlen);
> + __set_tcb_field_direct(csk, req, word, mask, val, cookie, no_reply);
> + set_wr_txq(skb, CPL_PRIORITY_CONTROL, csk->port_id);
> +}
> +
> +/*
> + * Send control message to HW, message go as immediate data and packet
> + * is freed immediately.
> + */
> +static void chtls_set_tcb_field(struct sock *sk, u16 word, u64 mask, u64 val)
> +{
> + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk);
> + struct cpl_set_tcb_field *req;
> + struct ulptx_idata *sc;
> + struct sk_buff *skb;
> + unsigned int wrlen = roundup(sizeof(*req) + sizeof(*sc), 16);
> + unsigned int credits_needed = DIV_ROUND_UP(wrlen, 16);
> +
> + skb = alloc_skb(wrlen, GFP_ATOMIC);
> + if (!skb)
> + return;
> +
> + __set_tcb_field(sk, skb, word, mask, val, 0, 1);
> + set_queue(skb, (csk->txq_idx << 1) | CPL_PRIORITY_DATA, sk);
> + csk->wr_credits -= credits_needed;
> + csk->wr_unacked += credits_needed;
> + enqueue_wr(csk, skb);
> + cxgb4_ofld_send(csk->egress_dev, skb);
> +}
What happens if e.g. alloc_skb() fails here? Is it fine to ignore the
error altogether?
> +
> +/*
> + * Set one of the t_flags bits in the TCB.
> + */
> +void chtls_set_tcb_tflag(struct sock *sk, unsigned int bit_pos, int val)
> +{
> + return chtls_set_tcb_field(sk, 1, 1ULL << bit_pos,
> + val << bit_pos);
> +}
> +
> +static void chtls_set_tcb_keyid(struct sock *sk, int keyid)
> +{
> + return chtls_set_tcb_field(sk, 31, 0xFFFFFFFFULL, keyid);
> +}
> +
> +static void chtls_set_tcb_seqno(struct sock *sk)
> +{
> + return chtls_set_tcb_field(sk, 28, ~0ULL, 0);
> +}
> +
> +static void chtls_set_tcb_quiesce(struct sock *sk, int val)
> +{
> + return chtls_set_tcb_field(sk, 1, (1ULL << TF_RX_QUIESCE_S),
> + TF_RX_QUIESCE_V(val));
> +}
Why would you return from a void function?
IMHO, it would be more productive if you could address the comments you
are receiving a bit more carefully instead of patching them up quickly
and race to re-post, because this doesn't seem to gain any time.
--
Stefano
next prev parent reply other threads:[~2018-03-12 13:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 19:10 [PATCH v10 crypto 02/11] ethtool: enable Inline TLS in HW Atul Gupta
2018-03-09 19:10 ` [PATCH v10 crypto 03/11] cxgb4: Inline TLS FW Interface Atul Gupta
2018-03-09 19:10 ` [PATCH v10 crypto 04/11] chtls: structure and macro definiton Atul Gupta
2018-03-09 19:10 ` [PATCH v10 crypto 05/11] cxgb4: LLD driver changes to enable TLS Atul Gupta
2018-03-09 19:10 ` [PATCH v10 crypto 06/11] chcr: Inline TLS Key Macros Atul Gupta
2018-03-09 19:10 ` [PATCH v10 crypto 07/11] chtls: Program the TLS Key Atul Gupta
2018-03-12 13:30 ` Stefano Brivio [this message]
2018-03-09 19:10 ` [PATCH v10 crypto 08/11] chtls: CPL handler definition Atul Gupta
2018-03-12 13:28 ` Stefano Brivio
2018-03-09 19:10 ` [PATCH v10 crypto 09/11] chtls: Inline TLS request Tx/Rx Atul Gupta
2018-03-12 13:28 ` Stefano Brivio
2018-03-09 19:10 ` [PATCH v10 crypto 10/11] chtls: Register chtls Inline TLS with net tls Atul Gupta
2018-03-09 19:10 ` [PATCH v10 crypto 11/11] Makefile Kconfig Atul Gupta
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=20180312143014.2cb8a4be@epycfail \
--to=sbrivio@redhat.com \
--cc=atul.gupta@chelsio.com \
--cc=davejwatson@fb.com \
--cc=davem@davemloft.net \
--cc=ganeshgr@chelsio.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
/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).