netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Pismenny <borisp@mellanox.com>
To: Rohit Maheshwari <rohitm@chelsio.com>,
	netdev@vger.kernel.org, davem@davemloft.net,
	herbert@gondor.apana.org.au
Cc: secdev@chelsio.com, varun@chelsio.com, kuba@kernel.org
Subject: Re: [PATCH net-next v3 1/6] cxgb4/chcr : Register to tls add and del callback
Date: Sun, 1 Mar 2020 10:36:01 +0200	[thread overview]
Message-ID: <57eb8055-a4ad-1afd-b4f4-07bbeaa2b6f6@mellanox.com> (raw)
In-Reply-To: <20200229012426.30981-2-rohitm@chelsio.com>

Hi Rohit,

On 2/29/2020 3:24 AM, Rohit Maheshwari wrote:
> A new macro is defined to enable ktls tx offload support on Chelsio
> T6 adapter. And if this macro is enabled, cxgb4 will send mailbox to
> enable or disable ktls settings on HW.
> In chcr, enabled tx offload flag in netdev and registered tls_dev_add
> and tls_dev_del.
>
> v1->v2:
> - mark tcb state to close in tls_dev_del.
> - u_ctx is now picked from adapter structure.
> - clear atid in case of failure.
> - corrected ULP_CRYPTO_KTLS_INLINE value.
>
> v2->v3:
> - add empty line after variable declaration.
> - local variable declaration in reverse christmas tree ordering.
>
> Signed-off-by: Rohit Maheshwari <rohitm@chelsio.com>
> ---
...
> +
> +/*
> + * chcr_ktls_dev_add:  call back for tls_dev_add.
> + * Create a tcb entry for TP. Also add l2t entry for the connection. And
> + * generate keys & save those keys locally.
> + * @netdev - net device.
> + * @tls_cts - tls context.
> + * @direction - TX/RX crypto direction
> + * return: SUCCESS/FAILURE.
> + */
> +static int chcr_ktls_dev_add(struct net_device *netdev, struct sock *sk,
> +			     enum tls_offload_ctx_dir direction,
> +			     struct tls_crypto_info *crypto_info,
> +			     u32 start_offload_tcp_sn)
> +{
> +	struct tls_context *tls_ctx = tls_get_ctx(sk);
> +	struct chcr_ktls_ofld_ctx_tx *tx_ctx;
> +	struct chcr_ktls_info *tx_info;
> +	struct dst_entry *dst;
> +	struct adapter *adap;
> +	struct port_info *pi;
> +	struct neighbour *n;
> +	u8 daaddr[16];
> +	int ret = -1;
> +
> +	tx_ctx = chcr_get_ktls_tx_context(tls_ctx);
> +
> +	pi = netdev_priv(netdev);
> +	adap = pi->adapter;
> +	if (direction == TLS_OFFLOAD_CTX_DIR_RX) {
> +		pr_err("not expecting for RX direction\n");
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +	if (tx_ctx->chcr_info) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	tx_info = kvzalloc(sizeof(*tx_info), GFP_KERNEL);
> +	if (!tx_info) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	spin_lock_init(&tx_info->lock);
> +
> +	/* clear connection state */
> +	spin_lock(&tx_info->lock);
> +	tx_info->connection_state = KTLS_CONN_CLOSED;
> +	spin_unlock(&tx_info->lock);
> +
> +	tx_info->sk = sk;
> +	/* initialize tid and atid to -1, 0 is a also a valid id. */
> +	tx_info->tid = -1;
> +	tx_info->atid = -1;
> +
> +	tx_info->adap = adap;
> +	tx_info->netdev = netdev;
> +	tx_info->tx_chan = pi->tx_chan;
> +	tx_info->smt_idx = pi->smt_idx;
> +	tx_info->port_id = pi->port_id;
> +
> +	tx_info->rx_qid = chcr_get_first_rx_qid(adap);
> +	if (unlikely(tx_info->rx_qid < 0))
> +		goto out2;
> +
> +	tx_info->prev_seq = start_offload_tcp_sn;
> +	tx_info->tcp_start_seq_number = start_offload_tcp_sn;
> +
> +	/* get peer ip */
> +	if (sk->sk_family == AF_INET ||
> +	    (sk->sk_family == AF_INET6 && !sk->sk_ipv6only &&
> +	     ipv6_addr_type(&sk->sk_v6_daddr) == IPV6_ADDR_MAPPED)) {
> +		memcpy(daaddr, &sk->sk_daddr, 4);
> +	} else {
> +		goto out2;
> +	}
> +
> +	/* get the l2t index */
> +	dst = sk_dst_get(sk);
> +	if (!dst) {
> +		pr_err("DST entry not found\n");
> +		goto out2;
> +	}
> +	n = dst_neigh_lookup(dst, daaddr);
> +	if (!n || !n->dev) {
> +		pr_err("neighbour not found\n");
> +		dst_release(dst);
> +		goto out2;
> +	}
> +	tx_info->l2te  = cxgb4_l2t_get(adap->l2t, n, n->dev, 0);

I see that you make an effort to obtain the the L2 tunnel, but did you test it? I would expect that offload would fail for such a connection as the KTLS code would not find the lower device with the offload capability..

If this doesn't work, better remove it, until the stack supports such functionality. Then, you wouldn't need to retrospectively obtain these parameters. Instead, you could just implement the proper flow by working with the L2 tunnel.

> +
> +	neigh_release(n);
> +	dst_release(dst);
> +
> +	if (!tx_info->l2te) {
> +		pr_err("l2t entry not found\n");
> +		goto out2;
> +	}
> +
> +	tx_ctx->chcr_info = tx_info;
> +
> +	/* create a filter and call cxgb4_l2t_send to send the packet out, which
> +	 * will take care of updating l2t entry in hw if not already done.
> +	 */
> +	ret = chcr_setup_connection(sk, tx_info);
> +	if (ret)
> +		goto out2;
> +
> +	return 0;
> +out2:
> +	kvfree(tx_info);
> +out:
> +	return ret;
> +}
> +
...

  reply	other threads:[~2020-03-01  8:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-29  1:24 [PATCH net-next v3 0/6] cxgb4/chcr: ktls tx offload support on T6 adapter Rohit Maheshwari
2020-02-29  1:24 ` [PATCH net-next v3 1/6] cxgb4/chcr : Register to tls add and del callback Rohit Maheshwari
2020-03-01  8:36   ` Boris Pismenny [this message]
2020-03-04 15:49     ` rohit maheshwari
2020-03-04 17:15       ` Boris Pismenny
2020-03-05 11:31         ` rohit maheshwari
2020-02-29  1:24 ` [PATCH net-next v3 2/6] cxgb4/chcr: Save tx keys and handle HW response Rohit Maheshwari
2020-02-29  1:24 ` [PATCH net-next v3 3/6] cxgb4/chcr: complete record tx handling Rohit Maheshwari
2020-03-01  8:35   ` Boris Pismenny
2020-03-04 15:47     ` rohit maheshwari
2020-03-04 17:08       ` Boris Pismenny
2020-03-05 11:28         ` rohit maheshwari
2020-03-05  0:49   ` kbuild test robot
2020-02-29  1:24 ` [PATCH net-next v3 4/6] chcr: handle partial end part of a record Rohit Maheshwari
2020-02-29  1:24 ` [PATCH net-next v3 5/6] chcr: Handle first or middle part of record Rohit Maheshwari
2020-02-29  1:24 ` [PATCH net-next v3 6/6] cxgb4/chcr: Add ipv6 support and statistics Rohit Maheshwari
2020-03-04 17:05   ` Boris Pismenny
2020-03-05 11:29     ` rohit maheshwari

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=57eb8055-a4ad-1afd-b4f4-07bbeaa2b6f6@mellanox.com \
    --to=borisp@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rohitm@chelsio.com \
    --cc=secdev@chelsio.com \
    --cc=varun@chelsio.com \
    /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).