* Re: [PATCH v3 net-next 00/19] Add ionic driver
From: David Miller @ 2019-07-09 2:58 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190708192532.27420-1-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Mon, 8 Jul 2019 12:25:13 -0700
> This is a patch series that adds the ionic driver, supporting the Pensando
> ethernet device.
...
I think with the review comments and feedback still coming in you will
have to wait until the next merge window, sorry.
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: David Miller @ 2019-07-09 2:57 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, mcroce, fw
In-Reply-To: <20190709102728.70299ba8@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jul 2019 10:27:28 +1000
> I am still getting this conflict (the commit ids may have changed).
> Just a reminder in case you think Linus may need to know.
I'm resolving this right now, thanks Stephen.
^ permalink raw reply
* Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support
From: wenxu @ 2019-07-09 2:56 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20190708141730.ozycgmtrub7ok2qs@breakpoint.cc>
On 7/8/2019 10:17 PM, Florian Westphal wrote:
> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> Add nf_nat_bridge_ops to do nat in the bridge family
> Whats the use case for this?
>
> The reason I'm asking is that a bridge doesn't know about IP,
> Bridge netfilter (the call-iptables thing) has a lot of glue code
> to detect dnat rewrites and updates target mac address, including
> support for redirect (suddently packet has to be pushed up the stack)
> or changes in the oif to non-bridge ports (it even checks forward sysctl
> state ..) and so on.
>
> Thats something that I don't want to support in nftables.
>
> For NAT on bridge, it should be possible already to push such packets
> up the stack by
>
> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
> meta pkttype set unicast ether daddr set 00:11:22:33:44:55
yes, packet can be push up to IP stack to handle the nat through bridge device.
In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
is the same known by outer. So The bridge can just do nat( without modify mac address or oif).
But in This case modify the packet dmac to bridge device, the packet push up through bridge device
Then do nat and route send back to bridge device.
^ permalink raw reply
* [PATCH net-next 11/11] net/tls: fix socket wmem accounting on fallback with netem
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
netem runs skb_orphan_partial() which "disconnects" the skb
from normal TCP write memory accounting. We should not adjust
sk->sk_wmem_alloc on the fallback path for such skbs.
Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
net/tls/tls_device_fallback.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/tls/tls_device_fallback.c b/net/tls/tls_device_fallback.c
index 1d2d804ac633..9070d68a92a4 100644
--- a/net/tls/tls_device_fallback.c
+++ b/net/tls/tls_device_fallback.c
@@ -209,6 +209,10 @@ static void complete_skb(struct sk_buff *nskb, struct sk_buff *skb, int headln)
update_chksum(nskb, headln);
+ /* sock_efree means skb must gone through skb_orphan_partial() */
+ if (nskb->destructor == sock_efree)
+ return;
+
delta = nskb->truesize - skb->truesize;
if (likely(delta < 0))
WARN_ON_ONCE(refcount_sub_and_test(-delta, &sk->sk_wmem_alloc));
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 10/11] nfp: tls: undo TLS sequence tracking when dropping the frame
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
If driver has to drop the TLS frame it needs to undo the TCP
sequence tracking changes, otherwise device will receive
segments out of order and drop them.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
.../ethernet/netronome/nfp/nfp_net_common.c | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 54dd98b2d645..9903805717da 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -893,6 +893,28 @@ nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
return skb;
}
+static void nfp_net_tls_tx_undo(struct sk_buff *skb, u64 tls_handle)
+{
+#ifdef CONFIG_TLS_DEVICE
+ struct nfp_net_tls_offload_ctx *ntls;
+ u32 datalen, seq;
+
+ if (!tls_handle)
+ return;
+ if (WARN_ON_ONCE(!skb->sk || !tls_is_sk_tx_device_offloaded(skb->sk)))
+ return;
+
+ datalen = skb->len - (skb_transport_offset(skb) + tcp_hdrlen(skb));
+ seq = ntohl(tcp_hdr(skb)->seq);
+
+ ntls = tls_driver_ctx(skb->sk, TLS_OFFLOAD_CTX_DIR_TX);
+ if (ntls->next_seq == seq + datalen)
+ ntls->next_seq = seq;
+ else
+ WARN_ON_ONCE(1);
+#endif
+}
+
static void nfp_net_tx_xmit_more_flush(struct nfp_net_tx_ring *tx_ring)
{
wmb();
@@ -1102,6 +1124,7 @@ static int nfp_net_tx(struct sk_buff *skb, struct net_device *netdev)
u64_stats_update_begin(&r_vec->tx_sync);
r_vec->tx_errors++;
u64_stats_update_end(&r_vec->tx_sync);
+ nfp_net_tls_tx_undo(skb, tls_handle);
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 08/11] net/tls: add missing prot info init
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Turns out TLS_TX in HW offload mode does not initialize tls_prot_info.
Since commit 9cd81988cce1 ("net/tls: use version from prot") we actually
use this field on the datapath. Luckily we always compare it to TLS 1.3,
and assume 1.2 otherwise. So since zero is not equal to 1.3, everything
worked fine.
Fixes: 9cd81988cce1 ("net/tls: use version from prot")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
net/tls/tls_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 56135f3ff4ff..06c30f677f7a 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -878,6 +878,8 @@ int tls_set_device_offload(struct sock *sk, struct tls_context *ctx)
goto free_offload_ctx;
}
+ prot->version = crypto_info->version;
+ prot->cipher_type = crypto_info->cipher_type;
prot->prepend_size = TLS_HEADER_SIZE + nonce_size;
prot->tag_size = tag_size;
prot->overhead_size = prot->prepend_size + prot->tag_size;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 09/11] nfp: tls: avoid one of the ifdefs for TLS
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Move the #ifdef CONFIG_TLS_DEVICE a little so we can eliminate
the other one.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 9a4421df9be9..54dd98b2d645 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -822,11 +822,11 @@ static void nfp_net_tx_csum(struct nfp_net_dp *dp,
u64_stats_update_end(&r_vec->tx_sync);
}
-#ifdef CONFIG_TLS_DEVICE
static struct sk_buff *
nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
struct sk_buff *skb, u64 *tls_handle, int *nr_frags)
{
+#ifdef CONFIG_TLS_DEVICE
struct nfp_net_tls_offload_ctx *ntls;
struct sk_buff *nskb;
bool resync_pending;
@@ -889,9 +889,9 @@ nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
memcpy(tls_handle, ntls->fw_handle, sizeof(ntls->fw_handle));
ntls->next_seq += datalen;
+#endif
return skb;
}
-#endif
static void nfp_net_tx_xmit_more_flush(struct nfp_net_tx_ring *tx_ring)
{
@@ -985,13 +985,11 @@ static int nfp_net_tx(struct sk_buff *skb, struct net_device *netdev)
return NETDEV_TX_BUSY;
}
-#ifdef CONFIG_TLS_DEVICE
skb = nfp_net_tls_tx(dp, r_vec, skb, &tls_handle, &nr_frags);
if (unlikely(!skb)) {
nfp_net_tx_xmit_more_flush(tx_ring);
return NETDEV_TX_OK;
}
-#endif
md_bytes = nfp_net_prep_tx_meta(skb, tls_handle);
if (unlikely(md_bytes < 0))
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 07/11] nfp: tls: don't leave key material in freed FW cmsg skbs
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Make sure the contents of the skb which carried key material
to the FW is cleared.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/crypto/tls.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index d448c6de8ea4..96a96b35c0ca 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -4,6 +4,7 @@
#include <linux/bitfield.h>
#include <linux/ipv6.h>
#include <linux/skbuff.h>
+#include <linux/string.h>
#include <net/tls.h>
#include "../ccm.h"
@@ -340,8 +341,22 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
memcpy(&back->salt, tls_ci->salt, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
memcpy(back->rec_no, tls_ci->rec_seq, sizeof(tls_ci->rec_seq));
+ /* Get an extra ref on the skb so we can wipe the key after */
+ skb_get(skb);
+
err = nfp_ccm_mbox_communicate(nn, skb, NFP_CCM_TYPE_CRYPTO_ADD,
sizeof(*reply), sizeof(*reply));
+ reply = (void *)skb->data;
+
+ /* We depend on CCM MBOX code not reallocating skb we sent
+ * so we can clear the key material out of the memory.
+ */
+ if (!WARN_ON_ONCE((u8 *)back < skb->head ||
+ (u8 *)back > skb_end_pointer(skb)) &&
+ !WARN_ON_ONCE((u8 *)&reply[1] > (u8 *)back))
+ memzero_explicit(back, sizeof(*back));
+ dev_consume_skb_any(skb); /* the extra ref from skb_get() above */
+
if (err) {
nn_dp_warn(&nn->dp, "failed to add TLS: %d (%d)\n",
err, direction == TLS_OFFLOAD_CTX_DIR_TX);
@@ -349,7 +364,6 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
goto err_conn_remove;
}
- reply = (void *)skb->data;
err = -be32_to_cpu(reply->error);
if (err) {
if (err == -ENOSPC) {
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 06/11] net/tls: don't clear TX resync flag on error
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Dirk van der Merwe,
Jakub Kicinski
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Introduce a return code for the tls_dev_resync callback.
When the driver TX resync fails, kernel can retry the resync again
until it succeeds. This prevents drivers from attempting to offload
TLS packets if the connection is known to be out of sync.
We don't worry about the RX resync since they will be retried naturally
as more encrypted records get received.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../net/ethernet/mellanox/mlx5/core/en_accel/tls.c | 8 +++++---
drivers/net/ethernet/netronome/nfp/crypto/tls.c | 13 +++++++++----
include/net/tls.h | 6 +++---
net/tls/tls_device.c | 8 ++++++--
4 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
index f8b93b62a7d2..ca07c86427a7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
@@ -160,9 +160,9 @@ static void mlx5e_tls_del(struct net_device *netdev,
direction == TLS_OFFLOAD_CTX_DIR_TX);
}
-static void mlx5e_tls_resync(struct net_device *netdev, struct sock *sk,
- u32 seq, u8 *rcd_sn_data,
- enum tls_offload_ctx_dir direction)
+static int mlx5e_tls_resync(struct net_device *netdev, struct sock *sk,
+ u32 seq, u8 *rcd_sn_data,
+ enum tls_offload_ctx_dir direction)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct mlx5e_priv *priv = netdev_priv(netdev);
@@ -177,6 +177,8 @@ static void mlx5e_tls_resync(struct net_device *netdev, struct sock *sk,
be64_to_cpu(rcd_sn));
mlx5_accel_tls_resync_rx(priv->mdev, rx_ctx->handle, seq, rcd_sn);
atomic64_inc(&priv->tls->sw_stats.rx_tls_resync_reply);
+
+ return 0;
}
static const struct tlsdev_ops mlx5e_tls_ops = {
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index b49405b4af55..d448c6de8ea4 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -403,7 +403,7 @@ nfp_net_tls_del(struct net_device *netdev, struct tls_context *tls_ctx,
nfp_net_tls_del_fw(nn, ntls->fw_handle);
}
-static void
+static int
nfp_net_tls_resync(struct net_device *netdev, struct sock *sk, u32 seq,
u8 *rcd_sn, enum tls_offload_ctx_dir direction)
{
@@ -412,11 +412,12 @@ nfp_net_tls_resync(struct net_device *netdev, struct sock *sk, u32 seq,
struct nfp_crypto_req_update *req;
struct sk_buff *skb;
gfp_t flags;
+ int err;
flags = direction == TLS_OFFLOAD_CTX_DIR_TX ? GFP_KERNEL : GFP_ATOMIC;
skb = nfp_net_tls_alloc_simple(nn, sizeof(*req), flags);
if (!skb)
- return;
+ return -ENOMEM;
ntls = tls_driver_ctx(sk, direction);
req = (void *)skb->data;
@@ -428,13 +429,17 @@ nfp_net_tls_resync(struct net_device *netdev, struct sock *sk, u32 seq,
memcpy(req->rec_no, rcd_sn, sizeof(req->rec_no));
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- nfp_net_tls_communicate_simple(nn, skb, "sync",
- NFP_CCM_TYPE_CRYPTO_UPDATE);
+ err = nfp_net_tls_communicate_simple(nn, skb, "sync",
+ NFP_CCM_TYPE_CRYPTO_UPDATE);
+ if (err)
+ return err;
ntls->next_seq = seq;
} else {
nfp_ccm_mbox_post(nn, skb, NFP_CCM_TYPE_CRYPTO_UPDATE,
sizeof(struct nfp_crypto_reply_simple));
}
+
+ return 0;
}
static const struct tlsdev_ops nfp_net_tls_ops = {
diff --git a/include/net/tls.h b/include/net/tls.h
index 0279938386ab..0e4b9624361b 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -304,9 +304,9 @@ struct tlsdev_ops {
void (*tls_dev_del)(struct net_device *netdev,
struct tls_context *ctx,
enum tls_offload_ctx_dir direction);
- void (*tls_dev_resync)(struct net_device *netdev,
- struct sock *sk, u32 seq, u8 *rcd_sn,
- enum tls_offload_ctx_dir direction);
+ int (*tls_dev_resync)(struct net_device *netdev,
+ struct sock *sk, u32 seq, u8 *rcd_sn,
+ enum tls_offload_ctx_dir direction);
};
enum tls_offload_sync_type {
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 40076f423dcb..56135f3ff4ff 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -214,6 +214,7 @@ static void tls_device_resync_tx(struct sock *sk, struct tls_context *tls_ctx,
{
struct net_device *netdev;
struct sk_buff *skb;
+ int err = 0;
u8 *rcd_sn;
skb = tcp_write_queue_tail(sk);
@@ -225,9 +226,12 @@ static void tls_device_resync_tx(struct sock *sk, struct tls_context *tls_ctx,
down_read(&device_offload_lock);
netdev = tls_ctx->netdev;
if (netdev)
- netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq, rcd_sn,
- TLS_OFFLOAD_CTX_DIR_TX);
+ err = netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq,
+ rcd_sn,
+ TLS_OFFLOAD_CTX_DIR_TX);
up_read(&device_offload_lock);
+ if (err)
+ return;
clear_bit_unlock(TLS_TX_SYNC_SCHED, &tls_ctx->flags);
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 05/11] nfp: tls: count TSO segments separately for the TLS offload
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Count the number of successfully submitted TLS segments,
not skbs. This will make it easier to compare the TLS
encryption count against other counters.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 270334427448..9a4421df9be9 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -880,7 +880,10 @@ nfp_net_tls_tx(struct nfp_net_dp *dp, struct nfp_net_r_vector *r_vec,
if (datalen) {
u64_stats_update_begin(&r_vec->tx_sync);
- r_vec->hw_tls_tx++;
+ if (!skb_is_gso(skb))
+ r_vec->hw_tls_tx++;
+ else
+ r_vec->hw_tls_tx += skb_shinfo(skb)->gso_segs;
u64_stats_update_end(&r_vec->tx_sync);
}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 04/11] nfp: ccm: increase message limits
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Dirk van der Merwe,
Jakub Kicinski
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Increase the batch limit to consume small message bursts more
effectively. Practically, the effect on the 'add' messages is not
significant since the mailbox is sized such that the 'add' messages are
still limited to the same order of magnitude that it was originally set
for.
Furthermore, increase the queue size limit to 1024 entries. This further
improves the handling of bursts of small control messages.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/ccm_mbox.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
index d160ac794d98..f0783aa9e66e 100644
--- a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
+++ b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
@@ -13,7 +13,7 @@
* form a batch. Threads come in with CMSG formed in an skb, then
* enqueue that skb onto the request queue. If threads skb is first
* in queue this thread will handle the mailbox operation. It copies
- * up to 16 messages into the mailbox (making sure that both requests
+ * up to 64 messages into the mailbox (making sure that both requests
* and replies will fit. After FW is done processing the batch it
* copies the data out and wakes waiting threads.
* If a thread is waiting it either gets its the message completed
@@ -23,9 +23,9 @@
* to limit potential cache line bounces.
*/
-#define NFP_CCM_MBOX_BATCH_LIMIT 16
+#define NFP_CCM_MBOX_BATCH_LIMIT 64
#define NFP_CCM_TIMEOUT (NFP_NET_POLL_TIMEOUT * 1000)
-#define NFP_CCM_MAX_QLEN 256
+#define NFP_CCM_MAX_QLEN 1024
enum nfp_net_mbox_cmsg_state {
NFP_NET_MBOX_CMSG_STATE_QUEUED,
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 03/11] nfp: tls: use unique connection ids instead of 4-tuple for TX
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Connection 4 tuple reuse is slightly problematic - TLS socket
and context do not get destroyed until all the associated skbs
left the system and all references are released. This leads
to stale connection entry in the device preventing addition
of new one if the 4 tuple is reused quickly enough.
Instead of using read 4 tuple as the key use a unique ID.
Set the protocol to TCP and port to 0 to ensure no collisions
with real connections.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
.../net/ethernet/netronome/nfp/crypto/fw.h | 2 +
.../net/ethernet/netronome/nfp/crypto/tls.c | 43 +++++++++++++------
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 ++
3 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/fw.h b/drivers/net/ethernet/netronome/nfp/crypto/fw.h
index 192ba907d91b..67413d946c4a 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/fw.h
+++ b/drivers/net/ethernet/netronome/nfp/crypto/fw.h
@@ -31,6 +31,8 @@ struct nfp_crypto_req_add_front {
u8 key_len;
__be16 ipver_vlan __packed;
u8 l4_proto;
+#define NFP_NET_TLS_NON_ADDR_KEY_LEN 8
+ u8 l3_addrs[0];
};
struct nfp_crypto_req_add_back {
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index b13b3dbd4843..b49405b4af55 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -155,17 +155,30 @@ nfp_net_tls_set_ipver_vlan(struct nfp_crypto_req_add_front *front, u8 ipver)
NFP_NET_TLS_VLAN_UNUSED));
}
+static void
+nfp_net_tls_assign_conn_id(struct nfp_net *nn,
+ struct nfp_crypto_req_add_front *front)
+{
+ u32 len;
+ u64 id;
+
+ id = atomic64_inc_return(&nn->ktls_conn_id_gen);
+ len = front->key_len - NFP_NET_TLS_NON_ADDR_KEY_LEN;
+
+ memcpy(front->l3_addrs, &id, sizeof(id));
+ memset(front->l3_addrs + sizeof(id), 0, len - sizeof(id));
+}
+
static struct nfp_crypto_req_add_back *
-nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
- int direction)
+nfp_net_tls_set_ipv4(struct nfp_net *nn, struct nfp_crypto_req_add_v4 *req,
+ struct sock *sk, int direction)
{
struct inet_sock *inet = inet_sk(sk);
req->front.key_len += sizeof(__be32) * 2;
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- req->src_ip = inet->inet_saddr;
- req->dst_ip = inet->inet_daddr;
+ nfp_net_tls_assign_conn_id(nn, &req->front);
} else {
req->src_ip = inet->inet_daddr;
req->dst_ip = inet->inet_saddr;
@@ -175,8 +188,8 @@ nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
}
static struct nfp_crypto_req_add_back *
-nfp_net_tls_set_ipv6(struct nfp_crypto_req_add_v6 *req, struct sock *sk,
- int direction)
+nfp_net_tls_set_ipv6(struct nfp_net *nn, struct nfp_crypto_req_add_v6 *req,
+ struct sock *sk, int direction)
{
#if IS_ENABLED(CONFIG_IPV6)
struct ipv6_pinfo *np = inet6_sk(sk);
@@ -184,8 +197,7 @@ nfp_net_tls_set_ipv6(struct nfp_crypto_req_add_v6 *req, struct sock *sk,
req->front.key_len += sizeof(struct in6_addr) * 2;
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- memcpy(req->src_ip, &np->saddr, sizeof(req->src_ip));
- memcpy(req->dst_ip, &sk->sk_v6_daddr, sizeof(req->dst_ip));
+ nfp_net_tls_assign_conn_id(nn, &req->front);
} else {
memcpy(req->src_ip, &sk->sk_v6_daddr, sizeof(req->src_ip));
memcpy(req->dst_ip, &np->saddr, sizeof(req->dst_ip));
@@ -205,8 +217,8 @@ nfp_net_tls_set_l4(struct nfp_crypto_req_add_front *front,
front->l4_proto = IPPROTO_TCP;
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
- back->src_port = inet->inet_sport;
- back->dst_port = inet->inet_dport;
+ back->src_port = 0;
+ back->dst_port = 0;
} else {
back->src_port = inet->inet_dport;
back->dst_port = inet->inet_sport;
@@ -260,6 +272,7 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
struct nfp_crypto_reply_add *reply;
struct sk_buff *skb;
size_t req_sz;
+ void *req;
bool ipv6;
int err;
@@ -302,16 +315,17 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
front = (void *)skb->data;
front->ep_id = 0;
- front->key_len = 8;
+ front->key_len = NFP_NET_TLS_NON_ADDR_KEY_LEN;
front->opcode = nfp_tls_1_2_dir_to_opcode(direction);
memset(front->resv, 0, sizeof(front->resv));
nfp_net_tls_set_ipver_vlan(front, ipv6 ? 6 : 4);
+ req = (void *)skb->data;
if (ipv6)
- back = nfp_net_tls_set_ipv6((void *)skb->data, sk, direction);
+ back = nfp_net_tls_set_ipv6(nn, req, sk, direction);
else
- back = nfp_net_tls_set_ipv4((void *)skb->data, sk, direction);
+ back = nfp_net_tls_set_ipv4(nn, req, sk, direction);
nfp_net_tls_set_l4(front, back, sk, direction);
@@ -329,7 +343,8 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
err = nfp_ccm_mbox_communicate(nn, skb, NFP_CCM_TYPE_CRYPTO_ADD,
sizeof(*reply), sizeof(*reply));
if (err) {
- nn_dp_warn(&nn->dp, "failed to add TLS: %d\n", err);
+ nn_dp_warn(&nn->dp, "failed to add TLS: %d (%d)\n",
+ err, direction == TLS_OFFLOAD_CTX_DIR_TX);
/* communicate frees skb on error */
goto err_conn_remove;
}
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net.h b/drivers/net/ethernet/netronome/nfp/nfp_net.h
index 0659756bf2bb..5d6c3738b494 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net.h
@@ -583,6 +583,7 @@ struct nfp_net_dp {
* @tlv_caps: Parsed TLV capabilities
* @ktls_tx_conn_cnt: Number of offloaded kTLS TX connections
* @ktls_rx_conn_cnt: Number of offloaded kTLS RX connections
+ * @ktls_conn_id_gen: Trivial generator for kTLS connection ids (for TX)
* @ktls_no_space: Counter of firmware rejecting kTLS connection due to
* lack of space
* @mbox_cmsg: Common Control Message via vNIC mailbox state
@@ -670,6 +671,8 @@ struct nfp_net {
unsigned int ktls_tx_conn_cnt;
unsigned int ktls_rx_conn_cnt;
+ atomic64_t ktls_conn_id_gen;
+
atomic_t ktls_no_space;
struct {
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 02/11] nfp: tls: move setting ipver_vlan to a helper
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
Long lines are ugly. No functional changes.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/crypto/tls.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index 086bea0a7f2d..b13b3dbd4843 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -147,6 +147,14 @@ static void nfp_net_tls_del_fw(struct nfp_net *nn, __be32 *fw_handle)
NFP_CCM_TYPE_CRYPTO_DEL);
}
+static void
+nfp_net_tls_set_ipver_vlan(struct nfp_crypto_req_add_front *front, u8 ipver)
+{
+ front->ipver_vlan = cpu_to_be16(FIELD_PREP(NFP_NET_TLS_IPVER, ipver) |
+ FIELD_PREP(NFP_NET_TLS_VLAN,
+ NFP_NET_TLS_VLAN_UNUSED));
+}
+
static struct nfp_crypto_req_add_back *
nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
int direction)
@@ -154,9 +162,6 @@ nfp_net_tls_set_ipv4(struct nfp_crypto_req_add_v4 *req, struct sock *sk,
struct inet_sock *inet = inet_sk(sk);
req->front.key_len += sizeof(__be32) * 2;
- req->front.ipver_vlan = cpu_to_be16(FIELD_PREP(NFP_NET_TLS_IPVER, 4) |
- FIELD_PREP(NFP_NET_TLS_VLAN,
- NFP_NET_TLS_VLAN_UNUSED));
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
req->src_ip = inet->inet_saddr;
@@ -177,9 +182,6 @@ nfp_net_tls_set_ipv6(struct nfp_crypto_req_add_v6 *req, struct sock *sk,
struct ipv6_pinfo *np = inet6_sk(sk);
req->front.key_len += sizeof(struct in6_addr) * 2;
- req->front.ipver_vlan = cpu_to_be16(FIELD_PREP(NFP_NET_TLS_IPVER, 6) |
- FIELD_PREP(NFP_NET_TLS_VLAN,
- NFP_NET_TLS_VLAN_UNUSED));
if (direction == TLS_OFFLOAD_CTX_DIR_TX) {
memcpy(req->src_ip, &np->saddr, sizeof(req->src_ip));
@@ -304,6 +306,8 @@ nfp_net_tls_add(struct net_device *netdev, struct sock *sk,
front->opcode = nfp_tls_1_2_dir_to_opcode(direction);
memset(front->resv, 0, sizeof(front->resv));
+ nfp_net_tls_set_ipver_vlan(front, ipv6 ? 6 : 4);
+
if (ipv6)
back = nfp_net_tls_set_ipv6((void *)skb->data, sk, direction);
else
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 01/11] nfp: tls: ignore queue limits for delete commands
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem
Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski,
Dirk van der Merwe
In-Reply-To: <20190709025318.5534-1-jakub.kicinski@netronome.com>
We need to do our best not to drop delete commands, otherwise
we will have stale entries in the connection table. Ignore
the control message queue limits for delete commands.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/ccm.h | 4 +++
drivers/net/ethernet/netronome/nfp/ccm_mbox.c | 25 +++++++++++++------
.../net/ethernet/netronome/nfp/crypto/tls.c | 5 ++--
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/ccm.h b/drivers/net/ethernet/netronome/nfp/ccm.h
index da1b1e20df51..a460c75522be 100644
--- a/drivers/net/ethernet/netronome/nfp/ccm.h
+++ b/drivers/net/ethernet/netronome/nfp/ccm.h
@@ -118,6 +118,10 @@ bool nfp_ccm_mbox_fits(struct nfp_net *nn, unsigned int size);
struct sk_buff *
nfp_ccm_mbox_msg_alloc(struct nfp_net *nn, unsigned int req_size,
unsigned int reply_size, gfp_t flags);
+int __nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
+ enum nfp_ccm_type type,
+ unsigned int reply_size,
+ unsigned int max_reply_size, bool critical);
int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
enum nfp_ccm_type type,
unsigned int reply_size,
diff --git a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
index 02fccd90961d..d160ac794d98 100644
--- a/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
+++ b/drivers/net/ethernet/netronome/nfp/ccm_mbox.c
@@ -515,13 +515,13 @@ nfp_ccm_mbox_msg_prepare(struct nfp_net *nn, struct sk_buff *skb,
static int
nfp_ccm_mbox_msg_enqueue(struct nfp_net *nn, struct sk_buff *skb,
- enum nfp_ccm_type type)
+ enum nfp_ccm_type type, bool critical)
{
struct nfp_ccm_hdr *hdr;
assert_spin_locked(&nn->mbox_cmsg.queue.lock);
- if (nn->mbox_cmsg.queue.qlen >= NFP_CCM_MAX_QLEN) {
+ if (!critical && nn->mbox_cmsg.queue.qlen >= NFP_CCM_MAX_QLEN) {
nn_dp_warn(&nn->dp, "mailbox request queue too long\n");
return -EBUSY;
}
@@ -536,10 +536,10 @@ nfp_ccm_mbox_msg_enqueue(struct nfp_net *nn, struct sk_buff *skb,
return 0;
}
-int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
- enum nfp_ccm_type type,
- unsigned int reply_size,
- unsigned int max_reply_size)
+int __nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
+ enum nfp_ccm_type type,
+ unsigned int reply_size,
+ unsigned int max_reply_size, bool critical)
{
int err;
@@ -550,7 +550,7 @@ int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
spin_lock_bh(&nn->mbox_cmsg.queue.lock);
- err = nfp_ccm_mbox_msg_enqueue(nn, skb, type);
+ err = nfp_ccm_mbox_msg_enqueue(nn, skb, type, critical);
if (err)
goto err_unlock;
@@ -594,6 +594,15 @@ int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
return err;
}
+int nfp_ccm_mbox_communicate(struct nfp_net *nn, struct sk_buff *skb,
+ enum nfp_ccm_type type,
+ unsigned int reply_size,
+ unsigned int max_reply_size)
+{
+ return __nfp_ccm_mbox_communicate(nn, skb, type, reply_size,
+ max_reply_size, false);
+}
+
static void nfp_ccm_mbox_post_runq_work(struct work_struct *work)
{
struct sk_buff *skb;
@@ -650,7 +659,7 @@ int nfp_ccm_mbox_post(struct nfp_net *nn, struct sk_buff *skb,
spin_lock_bh(&nn->mbox_cmsg.queue.lock);
- err = nfp_ccm_mbox_msg_enqueue(nn, skb, type);
+ err = nfp_ccm_mbox_msg_enqueue(nn, skb, type, false);
if (err)
goto err_unlock;
diff --git a/drivers/net/ethernet/netronome/nfp/crypto/tls.c b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
index 9f7ccb7da417..086bea0a7f2d 100644
--- a/drivers/net/ethernet/netronome/nfp/crypto/tls.c
+++ b/drivers/net/ethernet/netronome/nfp/crypto/tls.c
@@ -112,8 +112,9 @@ nfp_net_tls_communicate_simple(struct nfp_net *nn, struct sk_buff *skb,
struct nfp_crypto_reply_simple *reply;
int err;
- err = nfp_ccm_mbox_communicate(nn, skb, type,
- sizeof(*reply), sizeof(*reply));
+ err = __nfp_ccm_mbox_communicate(nn, skb, type,
+ sizeof(*reply), sizeof(*reply),
+ type == NFP_CCM_TYPE_CRYPTO_DEL);
if (err) {
nn_dp_warn(&nn->dp, "failed to %s TLS: %d\n", name, err);
return err;
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 00/11] nfp: tls: fixes for initial TLS support
From: Jakub Kicinski @ 2019-07-09 2:53 UTC (permalink / raw)
To: davem; +Cc: netdev, oss-drivers, alexei.starovoitov, Jakub Kicinski
Hi!
This series brings various fixes to nfp tls offload recently added
to net-next.
First 4 patches revolve around device mailbox communication, trying
to make it more reliable. Next patch fixes statistical counter.
Patch 6 improves the TX resync if device communication failed.
Patch 7 makes sure we remove keys from memory after talking to FW.
Patch 8 adds missing tls context initialization, we fill in the
context information from various places based on the configuration
and looks like we missed the init in the case of where TX is
offloaded, but RX wasn't initialized yet. Patches 9 and 10 make
the nfp driver undo TLS state changes if we need to drop the
frame (e.g. due to DMA mapping error).
Last but not least TLS fallback should not adjust socket memory
after skb_orphan_partial(). This code will go away once we forbid
orphaning of skbs in need of crypto, but that's "real" -next
material, so lets do a quick fix.
Dirk van der Merwe (2):
nfp: ccm: increase message limits
net/tls: don't clear TX resync flag on error
Jakub Kicinski (9):
nfp: tls: ignore queue limits for delete commands
nfp: tls: move setting ipver_vlan to a helper
nfp: tls: use unique connection ids instead of 4-tuple for TX
nfp: tls: count TSO segments separately for the TLS offload
nfp: tls: don't leave key material in freed FW cmsg skbs
net/tls: add missing prot info init
nfp: tls: avoid one of the ifdefs for TLS
nfp: tls: undo TLS sequence tracking when dropping the frame
net/tls: fix socket wmem accounting on fallback with netem
.../mellanox/mlx5/core/en_accel/tls.c | 8 +-
drivers/net/ethernet/netronome/nfp/ccm.h | 4 +
drivers/net/ethernet/netronome/nfp/ccm_mbox.c | 31 ++++---
.../net/ethernet/netronome/nfp/crypto/fw.h | 2 +
.../net/ethernet/netronome/nfp/crypto/tls.c | 93 +++++++++++++------
drivers/net/ethernet/netronome/nfp/nfp_net.h | 3 +
.../ethernet/netronome/nfp/nfp_net_common.c | 32 ++++++-
include/net/tls.h | 6 +-
net/tls/tls_device.c | 10 +-
net/tls/tls_device_fallback.c | 4 +
10 files changed, 143 insertions(+), 50 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
From: Jason Wang @ 2019-07-09 2:50 UTC (permalink / raw)
To: Tiwei Bie, Alex Williamson
Cc: mst, maxime.coquelin, linux-kernel, kvm, virtualization, netdev,
dan.daly, cunming.liang, zhihong.wang, idos, Rob Miller,
Ariel Adam
In-Reply-To: <20190708061625.GA15936@___>
On 2019/7/8 下午2:16, Tiwei Bie wrote:
> On Fri, Jul 05, 2019 at 08:49:46AM -0600, Alex Williamson wrote:
>> On Thu, 4 Jul 2019 14:21:34 +0800
>> Tiwei Bie <tiwei.bie@intel.com> wrote:
>>> On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote:
>>>> On 2019/7/3 下午9:08, Tiwei Bie wrote:
>>>>> On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
>>>>>> On 2019/7/3 下午7:52, Tiwei Bie wrote:
>>>>>>> On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
>>>>>>>> On 2019/7/3 下午5:13, Tiwei Bie wrote:
>>>>>>>>> Details about this can be found here:
>>>>>>>>>
>>>>>>>>> https://lwn.net/Articles/750770/
>>>>>>>>>
>>>>>>>>> What's new in this version
>>>>>>>>> ==========================
>>>>>>>>>
>>>>>>>>> A new VFIO device type is introduced - vfio-vhost. This addressed
>>>>>>>>> some comments from here:https://patchwork.ozlabs.org/cover/984763/
>>>>>>>>>
>>>>>>>>> Below is the updated device interface:
>>>>>>>>>
>>>>>>>>> Currently, there are two regions of this device: 1) CONFIG_REGION
>>>>>>>>> (VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to setup the
>>>>>>>>> device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX), which
>>>>>>>>> can be used to notify the device.
>>>>>>>>>
>>>>>>>>> 1. CONFIG_REGION
>>>>>>>>>
>>>>>>>>> The region described by CONFIG_REGION is the main control interface.
>>>>>>>>> Messages will be written to or read from this region.
>>>>>>>>>
>>>>>>>>> The message type is determined by the `request` field in message
>>>>>>>>> header. The message size is encoded in the message header too.
>>>>>>>>> The message format looks like this:
>>>>>>>>>
>>>>>>>>> struct vhost_vfio_op {
>>>>>>>>> __u64 request;
>>>>>>>>> __u32 flags;
>>>>>>>>> /* Flag values: */
>>>>>>>>> #define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need reply */
>>>>>>>>> __u32 size;
>>>>>>>>> union {
>>>>>>>>> __u64 u64;
>>>>>>>>> struct vhost_vring_state state;
>>>>>>>>> struct vhost_vring_addr addr;
>>>>>>>>> } payload;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> The existing vhost-kernel ioctl cmds are reused as the message
>>>>>>>>> requests in above structure.
>>>>>>>> Still a comments like V1. What's the advantage of inventing a new protocol?
>>>>>>> I'm trying to make it work in VFIO's way..
>>>>>>>
>>>>>>>> I believe either of the following should be better:
>>>>>>>>
>>>>>>>> - using vhost ioctl, we can start from SET_VRING_KICK/SET_VRING_CALL and
>>>>>>>> extend it with e.g notify region. The advantages is that all exist userspace
>>>>>>>> program could be reused without modification (or minimal modification). And
>>>>>>>> vhost API hides lots of details that is not necessary to be understood by
>>>>>>>> application (e.g in the case of container).
>>>>>>> Do you mean reusing vhost's ioctl on VFIO device fd directly,
>>>>>>> or introducing another mdev driver (i.e. vhost_mdev instead of
>>>>>>> using the existing vfio_mdev) for mdev device?
>>>>>> Can we simply add them into ioctl of mdev_parent_ops?
>>>>> Right, either way, these ioctls have to be and just need to be
>>>>> added in the ioctl of the mdev_parent_ops. But another thing we
>>>>> also need to consider is that which file descriptor the userspace
>>>>> will do the ioctl() on. So I'm wondering do you mean let the
>>>>> userspace do the ioctl() on the VFIO device fd of the mdev
>>>>> device?
>>>>>
>>>> Yes.
>>> Got it! I'm not sure what's Alex opinion on this. If we all
>>> agree with this, I can do it in this way.
>>>
>>>> Is there any other way btw?
>>> Just a quick thought.. Maybe totally a bad idea. I was thinking
>>> whether it would be odd to do non-VFIO's ioctls on VFIO's device
>>> fd. So I was wondering whether it's possible to allow binding
>>> another mdev driver (e.g. vhost_mdev) to the supported mdev
>>> devices. The new mdev driver, vhost_mdev, can provide similar
>>> ways to let userspace open the mdev device and do the vhost ioctls
>>> on it. To distinguish with the vfio_mdev compatible mdev devices,
>>> the device API of the new vhost_mdev compatible mdev devices
>>> might be e.g. "vhost-net" for net?
>>>
>>> So in VFIO case, the device will be for passthru directly. And
>>> in VHOST case, the device can be used to accelerate the existing
>>> virtualized devices.
>>>
>>> How do you think?
>> VFIO really can't prevent vendor specific ioctls on the device file
>> descriptor for mdevs, but a) we'd want to be sure the ioctl address
>> space can't collide with ioctls we'd use for vfio defined purposes and
>> b) maybe the VFIO user API isn't what you want in the first place if
>> you intend to mostly/entirely ignore the defined ioctl set and replace
>> them with your own. In the case of the latter, you're also not getting
>> the advantages of the existing VFIO userspace code, so why expose a
>> VFIO device at all.
> Yeah, I totally agree.
I guess the original idea is to reuse the VFIO DMA/IOMMU API for this.
Then we have the chance to reuse vfio codes in qemu for dealing with e.g
vIOMMU.
>
>> The mdev interface does provide a general interface for creating and
>> managing virtual devices, vfio-mdev is just one driver on the mdev
>> bus. Parav (Mellanox) has been doing work on mdev-core to help clean
>> out vfio-isms from the interface, aiui, with the intent of implementing
>> another mdev bus driver for using the devices within the kernel.
> Great to know this! I found below series after some searching:
>
> https://lkml.org/lkml/2019/3/8/821
>
> In above series, the new mlx5_core mdev driver will do the probe
> by calling mlx5_get_core_dev() first on the parent device of the
> mdev device. In vhost_mdev, maybe we can also keep track of all
> the compatible mdev devices and use this info to do the probe.
I don't get why this is needed. My understanding is if we want to go
this way, there're actually two parts. 1) Vhost mdev that implements the
device managements and vhost ioctl. 2) Vhost it self, which can accept
mdev fd as it backend through VHOST_NET_SET_BACKEND.
> But we also need a way to allow vfio_mdev driver to distinguish
> and reject the incompatible mdev devices.
One issue for this series is that it doesn't consider DMA isolation at all.
>
>> It
>> seems like this vhost-mdev driver might be similar, using mdev but not
>> necessarily vfio-mdev to expose devices. Thanks,
> Yeah, I also think so!
I've cced some driver developers for their inputs. I think we need a
sample parent drivers in the next version for us to understand the full
picture.
Thanks
>
> Thanks!
> Tiwei
>
>> Alex
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: allow up to four clocks for orion-mdio
From: Andrew Lunn @ 2019-07-09 2:41 UTC (permalink / raw)
To: Rob Herring; +Cc: josua, netdev, stable, David S. Miller, Mark Rutland
In-Reply-To: <CAL_JsqJJA6=2b=VzDzS1ipOatpRuVBUmReYoOMf-9p39=jyF8Q@mail.gmail.com>
> > Optional properties:
> > - interrupts: interrupt line number for the SMI error/done interrupt
> > -- clocks: phandle for up to three required clocks for the MDIO instance
> > +- clocks: phandle for up to four required clocks for the MDIO instance
>
> This needs to enumerate exactly what the clocks are. Shouldn't there
> be an additional clock-names value too?
Hi Rob
The driver does not care what they are called. It just turns them all
on, and turns them off again when removed.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2] skbuff: increase verbosity when dumping skb data
From: David Miller @ 2019-07-09 2:39 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, linyunsheng, willemb
In-Reply-To: <20190707095155.58578-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sun, 7 Jul 2019 05:51:55 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> skb_warn_bad_offload and netdev_rx_csum_fault trigger on hard to debug
> issues. Dump more state and the header.
>
> Optionally dump the entire packet and linear segment. This is required
> to debug checksum bugs that may include bytes past skb_tail_pointer().
>
> Both call sites call this function inside a net_ratelimit() block.
> Limit full packet log further to a hard limit of can_dump_full (5).
>
> Based on an earlier patch by Cong Wang, see link below.
>
> Changes v1 -> v2
> - dump frag_list only on full_pkt
>
> Link: https://patchwork.ozlabs.org/patch/1000841/
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Nice to finally have this, applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: elide flowlabel check if no exclusive leases exist
From: David Miller @ 2019-07-09 2:38 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, willemb
In-Reply-To: <20190707093445.15121-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sun, 7 Jul 2019 05:34:45 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Processes can request ipv6 flowlabels with cmsg IPV6_FLOWINFO.
> If not set, by default an autogenerated flowlabel is selected.
>
> Explicit flowlabels require a control operation per label plus a
> datapath check on every connection (every datagram if unconnected).
> This is particularly expensive on unconnected sockets multiplexing
> many flows, such as QUIC.
>
> In the common case, where no lease is exclusive, the check can be
> safely elided, as both lease request and check trivially succeed.
> Indeed, autoflowlabel does the same even with exclusive leases.
>
> Elide the check if no process has requested an exclusive lease.
>
> fl6_sock_lookup previously returns either a reference to a lease or
> NULL to denote failure. Modify to return a real error and update
> all callers. On return NULL, they can use the label and will elide
> the atomic_dec in fl6_sock_release.
>
> This is an optimization. Robust applications still have to revert to
> requesting leases if the fast path fails due to an exclusive lease.
>
> Changes RFC->v1:
> - use static_key_false_deferred to rate limit jump label operations
> - call static_key_deferred_flush to stop timers on exit
> - move decrement out of RCU context
> - defer optimization also if opt data is associated with a lease
> - updated all fp6_sock_lookup callers, not just udp
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Looks good, applied, thanks Willem.
^ permalink raw reply
* [PATCH 2/2 net-next] net: stmmac: add support for hash table size 128/256 in dwmac4
From: Biao Huang @ 2019-07-09 2:36 UTC (permalink / raw)
To: davem, Jose Abreu, andrew
Cc: Giuseppe Cavallaro, Alexandre Torgue, Maxime Coquelin,
Matthias Brugger, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, linux-mediatek, yt.shen, biao.huang, jianguo.zhang,
boon.leong.ong
In-Reply-To: <20190709023623.8358-1-biao.huang@mediatek.com>
1. get hash table size in hw feature reigster, and add support
for taller hash table(128/256) in dwmac4.
2. only clear GMAC_PACKET_FILTER bits used in this function,
to avoid side effect to functions of other bits.
stmmac selftests output log with flow control on:
ethtool -t eth0
The test result is PASS
The test extra info:
1. MAC Loopback 0
2. PHY Loopback -95
3. MMC Counters 0
4. EEE -95
5. Hash Filter MC 0
6. Perfect Filter UC 0
7. MC Filter 0
8. UC Filter 0
9. Flow Control 0
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 7 +--
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 4 +-
.../net/ethernet/stmicro/stmmac/dwmac4_core.c | 49 +++++++++++--------
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++
5 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 2403a65167b2..af91e6b15eaa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -325,6 +325,7 @@ struct dma_features {
/* 802.3az - Energy-Efficient Ethernet (EEE) */
unsigned int eee;
unsigned int av;
+ unsigned int hash_tb_sz;
unsigned int tsoen;
/* TX and RX csum */
unsigned int tx_coe;
@@ -423,9 +424,9 @@ struct mac_device_info {
struct mii_regs mii; /* MII register Addresses */
struct mac_link link;
void __iomem *pcsr; /* vpointer to device CSRs */
- int multicast_filter_bins;
- int unicast_filter_entries;
- int mcast_bits_log2;
+ unsigned int multicast_filter_bins;
+ unsigned int unicast_filter_entries;
+ unsigned int mcast_bits_log2;
unsigned int rx_csum;
unsigned int pcs;
unsigned int pmt;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 15a9f3c7cc6a..2ed11a581d80 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -15,8 +15,7 @@
/* MAC registers */
#define GMAC_CONFIG 0x00000000
#define GMAC_PACKET_FILTER 0x00000008
-#define GMAC_HASH_TAB_0_31 0x00000010
-#define GMAC_HASH_TAB_32_63 0x00000014
+#define GMAC_HASH_TAB(x) (0x10 + (x) * 4)
#define GMAC_RX_FLOW_CTRL 0x00000090
#define GMAC_QX_TX_FLOW_CTRL(x) (0x70 + x * 4)
#define GMAC_TXQ_PRTY_MAP0 0x98
@@ -181,6 +180,7 @@ enum power_event {
#define GMAC_HW_FEAT_MIISEL BIT(0)
/* MAC HW features1 bitmap */
+#define GMAC_HW_HASH_TB_SZ GENMASK(25, 24)
#define GMAC_HW_FEAT_AVSEL BIT(20)
#define GMAC_HW_TSOEN BIT(18)
#define GMAC_HW_TXFIFOSIZE GENMASK(10, 6)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 776077ec1a23..01c2e2d83e76 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -400,41 +400,50 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
struct net_device *dev)
{
void __iomem *ioaddr = (void __iomem *)dev->base_addr;
- unsigned int value = 0;
+ int numhashregs = (hw->multicast_filter_bins >> 5);
+ int mcbitslog2 = hw->mcast_bits_log2;
+ unsigned int value;
+ int i;
+ value = readl(ioaddr + GMAC_PACKET_FILTER);
+ value &= ~GMAC_PACKET_FILTER_HMC;
+ value &= ~GMAC_PACKET_FILTER_HPF;
+ value &= ~GMAC_PACKET_FILTER_PCF;
+ value &= ~GMAC_PACKET_FILTER_PM;
+ value &= ~GMAC_PACKET_FILTER_PR;
if (dev->flags & IFF_PROMISC) {
value = GMAC_PACKET_FILTER_PR | GMAC_PACKET_FILTER_PCF;
} else if ((dev->flags & IFF_ALLMULTI) ||
- (netdev_mc_count(dev) > HASH_TABLE_SIZE)) {
+ (netdev_mc_count(dev) > hw->multicast_filter_bins)) {
/* Pass all multi */
- value = GMAC_PACKET_FILTER_PM;
- /* Set the 64 bits of the HASH tab. To be updated if taller
- * hash table is used
- */
- writel(0xffffffff, ioaddr + GMAC_HASH_TAB_0_31);
- writel(0xffffffff, ioaddr + GMAC_HASH_TAB_32_63);
+ value |= GMAC_PACKET_FILTER_PM;
+ /* Set all the bits of the HASH tab */
+ for (i = 0; i < numhashregs; i++)
+ writel(0xffffffff, ioaddr + GMAC_HASH_TAB(i));
} else if (!netdev_mc_empty(dev)) {
- u32 mc_filter[2];
struct netdev_hw_addr *ha;
+ u32 mc_filter[8];
/* Hash filter for multicast */
- value = GMAC_PACKET_FILTER_HMC;
+ value |= GMAC_PACKET_FILTER_HMC;
memset(mc_filter, 0, sizeof(mc_filter));
netdev_for_each_mc_addr(ha, dev) {
- /* The upper 6 bits of the calculated CRC are used to
- * index the content of the Hash Table Reg 0 and 1.
+ /* The upper n bits of the calculated CRC are used to
+ * index the contents of the hash table. The number of
+ * bits used depends on the hardware configuration
+ * selected at core configuration time.
*/
- int bit_nr =
- (bitrev32(~crc32_le(~0, ha->addr, 6)) >> 26);
- /* The most significant bit determines the register
- * to use while the other 5 bits determines the bit
- * within the selected register
+ int bit_nr = bitrev32(~crc32_le(~0, ha->addr,
+ ETH_ALEN)) >> (32 - mcbitslog2);
+ /* The most significant bit determines the register to
+ * use (H/L) while the other 5 bits determine the bit
+ * within the register.
*/
- mc_filter[bit_nr >> 5] |= (1 << (bit_nr & 0x1F));
+ mc_filter[bit_nr >> 5] |= (1 << (bit_nr & 0x1f));
}
- writel(mc_filter[0], ioaddr + GMAC_HASH_TAB_0_31);
- writel(mc_filter[1], ioaddr + GMAC_HASH_TAB_32_63);
+ for (i = 0; i < numhashregs; i++)
+ writel(mc_filter[i], ioaddr + GMAC_HASH_TAB(i));
}
value |= GMAC_PACKET_FILTER_HPF;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 0f208e13da9f..6af79fd65ef7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -351,6 +351,7 @@ static void dwmac4_get_hw_feature(void __iomem *ioaddr,
/* MAC HW feature1 */
hw_cap = readl(ioaddr + GMAC_HW_FEATURE1);
+ dma_cap->hash_tb_sz = (hw_cap & GMAC_HW_HASH_TB_SZ) >> 24;
dma_cap->av = (hw_cap & GMAC_HW_FEAT_AVSEL) >> 20;
dma_cap->tsoen = (hw_cap & GMAC_HW_TSOEN) >> 18;
/* RX and TX FIFO sizes are encoded as log2(n / 128). Undo that by
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3425d4dda03d..3a04ace0379a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4174,6 +4174,12 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->plat->enh_desc = priv->dma_cap.enh_desc;
priv->plat->pmt = priv->dma_cap.pmt_remote_wake_up;
priv->hw->pmt = priv->plat->pmt;
+ if (priv->dma_cap.hash_tb_sz) {
+ priv->hw->multicast_filter_bins =
+ (BIT(priv->dma_cap.hash_tb_sz) << 5);
+ priv->hw->mcast_bits_log2 =
+ ilog2(priv->hw->multicast_filter_bins);
+ }
/* TXCOE doesn't work in thresh DMA mode */
if (priv->plat->force_thresh_dma_mode)
--
2.18.0
^ permalink raw reply related
* [PATCH 1/2 net-next] net: stmmac: dwmac4: mac address array boudary violation issue
From: Biao Huang @ 2019-07-09 2:36 UTC (permalink / raw)
To: davem, Jose Abreu, andrew
Cc: Giuseppe Cavallaro, Alexandre Torgue, Maxime Coquelin,
Matthias Brugger, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, linux-mediatek, yt.shen, biao.huang, jianguo.zhang,
boon.leong.ong
In-Reply-To: <20190709023623.8358-1-biao.huang@mediatek.com>
The mac address array size is GMAC_MAX_PERFECT_ADDRESSES,
so the 'reg' should be less than it, or will affect other registers.
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 8d9f6cda4012..776077ec1a23 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -454,7 +454,7 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
reg++;
}
- while (reg <= GMAC_MAX_PERFECT_ADDRESSES) {
+ while (reg < GMAC_MAX_PERFECT_ADDRESSES) {
writel(0, ioaddr + GMAC_ADDR_HIGH(reg));
writel(0, ioaddr + GMAC_ADDR_LOW(reg));
reg++;
--
2.18.0
^ permalink raw reply related
* [PATCH 0/2 net-next] fix out-of-boundary issue and add taller hash table support
From: Biao Huang @ 2019-07-09 2:36 UTC (permalink / raw)
To: davem, Jose Abreu, andrew
Cc: Giuseppe Cavallaro, Alexandre Torgue, Maxime Coquelin,
Matthias Brugger, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, linux-mediatek, yt.shen, biao.huang, jianguo.zhang,
boon.leong.ong
Fix mac address out-of-boundary issue in net-next tree.
and resend the patch which was discussed in
https://lore.kernel.org/patchwork/patch/1082117
but with no further progress.
Biao Huang (2):
net: stmmac: dwmac4: mac address array boudary violation issue
net: stmmac: add support for hash table size 128/256 in dwmac4
drivers/net/ethernet/stmicro/stmmac/common.h | 7 +--
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 4 +-
.../net/ethernet/stmicro/stmmac/dwmac4_core.c | 51 +++++++++++--------
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++
5 files changed, 43 insertions(+), 26 deletions(-)
--
2.18.0
^ permalink raw reply
* RE: [PATCH net-next v5 3/5] devlink: Introduce PCI PF port flavour and port attribute
From: Parav Pandit @ 2019-07-09 2:36 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev@vger.kernel.org, Jiri Pirko, Saeed Mahameed
In-Reply-To: <20190708141403.1c01c5de@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Tuesday, July 9, 2019 2:44 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: netdev@vger.kernel.org; Jiri Pirko <jiri@mellanox.com>; Saeed Mahameed
> <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next v5 3/5] devlink: Introduce PCI PF port flavour and
> port attribute
>
> On Sun, 7 Jul 2019 23:15:47 -0500, Parav Pandit wrote:
> > diff --git a/net/core/devlink.c b/net/core/devlink.c index
> > 3e5f8204c36f..88b2cf207cb2 100644
> > --- a/net/core/devlink.c
> > +++ b/net/core/devlink.c
> > @@ -519,6 +519,11 @@ static int devlink_nl_port_attrs_put(struct sk_buff
> *msg,
> > if (devlink_port->attrs.flavour != DEVLINK_PORT_FLAVOUR_PHYSICAL
> &&
> > devlink_port->attrs.flavour != DEVLINK_PORT_FLAVOUR_CPU &&
> > devlink_port->attrs.flavour != DEVLINK_PORT_FLAVOUR_DSA)
> > return 0;
> > + if (devlink_port->attrs.flavour == DEVLINK_PORT_FLAVOUR_PCI_PF) {
>
> Thanks for making the changes! I'm not sure how this would work, tho.
> We return early if flavour is not phys/cpu/dsa, so how can flavour be pci here?..
>
My bad. Hunk got applied at wrong place when I split the patch.
Correcting it along with physical to phys name change that Jiri suggested.
> > + if (nla_put_u16(msg, DEVLINK_ATTR_PORT_PCI_PF_NUMBER,
> > + attrs->pci_pf.pf))
> > + return -EMSGSIZE;
> > + }
> > if (nla_put_u32(msg, DEVLINK_ATTR_PORT_NUMBER,
> > attrs->physical.port_number))
> > return -EMSGSIZE;
^ permalink raw reply
* Re: [PATCH v3 net-next 13/19] ionic: Add initial ethtool support
From: Andrew Lunn @ 2019-07-09 2:30 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <20190708192532.27420-14-snelson@pensando.io>
> +static int ionic_nway_reset(struct net_device *netdev)
> +{
> + struct lif *lif = netdev_priv(netdev);
> + int err = 0;
> +
> + if (netif_running(netdev))
> + err = ionic_reset_queues(lif);
What does ionic_reset_queues() do? It sounds nothing like restarting
auto negotiation?
Andrew
^ permalink raw reply
* Re: [PATCH net] tcp: Reset bytes_acked and bytes_received when disconnecting
From: David Miller @ 2019-07-09 2:30 UTC (permalink / raw)
To: cpaasch; +Cc: netdev, edumazet
In-Reply-To: <20190706231307.98483-1-cpaasch@apple.com>
From: Christoph Paasch <cpaasch@apple.com>
Date: Sat, 06 Jul 2019 16:13:07 -0700
> If an app is playing tricks to reuse a socket via tcp_disconnect(),
> bytes_acked/received needs to be reset to 0. Otherwise tcp_info will
> report the sum of the current and the old connection..
>
> Cc: Eric Dumazet <edumazet@google.com>
> Fixes: 0df48c26d841 ("tcp: add tcpi_bytes_acked to tcp_info")
> Fixes: bdd1f9edacb5 ("tcp: add tcpi_bytes_received to tcp_info")
> Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Applied and queued up for -stable.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox