* [PATCH net 3/4] net/mlx4_core: Fix namespace misalignment in QinQ VST support commit
From: Tariq Toukan @ 2017-08-01 13:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Jack Morgenstein, Tariq Toukan
In-Reply-To: <1501595026-32368-1-git-send-email-tariqt@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
The cited commit introduced the following new enum value in file
include/linux/mlx4/device.h:
MLX4_DEV_CAP_FLAG2_SVLAN_BY_QP
However the value of MLX4_DEV_CAP_FLAG2_SVLAN_BY_QP needs to stay
consistent with the value used in another namespace in
function dump_dev_cap_flags2(), which is manually kept in sync.
The change here restores that consistency.
Fixes: 7c3d21c8153c ("net/mlx4_core: Preparation for VF vlan protocol 802.1ad")
Reported-by: Mukesh Kacker <mukesh.kacker@oracle.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 009dd03466d6..7c9502bae1cc 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -159,7 +159,7 @@ static void dump_dev_cap_flags2(struct mlx4_dev *dev, u64 flags)
[32] = "Loopback source checks support",
[33] = "RoCEv2 support",
[34] = "DMFS Sniffer support (UC & MC)",
- [35] = "QinQ VST mode support",
+ [36] = "QinQ VST mode support",
[37] = "sl to vl mapping table change event support",
};
int i;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/4] net/mlx4_core: Fix sl_to_vl_change bit offset in flags2 dump
From: Tariq Toukan @ 2017-08-01 13:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Jack Morgenstein, Tariq Toukan
In-Reply-To: <1501595026-32368-1-git-send-email-tariqt@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
The index value in function dump_dev_cap_flags2() for outputting
"sl to vl mapping table change event support" needs to be
consistent with the value of the enumerated constant
MLX4_DEV_CAP_FLAG2_SL_TO_VL_CHANGE_EVENT defined in file
include/linux/mlx4_device.h
The change here restores that consistency.
Fixes: fd10ed8e6f42 ("IB/mlx4: Fix possible vl/sl field mismatch in LRH header in QP1 packets")
Reported-by: Mukesh Kacker <mukesh.kacker@oracle.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index c165f16623a9..009dd03466d6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -160,7 +160,7 @@ static void dump_dev_cap_flags2(struct mlx4_dev *dev, u64 flags)
[33] = "RoCEv2 support",
[34] = "DMFS Sniffer support (UC & MC)",
[35] = "QinQ VST mode support",
- [36] = "sl to vl mapping table change event support"
+ [37] = "sl to vl mapping table change event support",
};
int i;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 4/4] net/mlx4_core: Fixes missing capability bit in flags2 capability dump
From: Tariq Toukan @ 2017-08-01 13:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Jack Morgenstein, Tariq Toukan
In-Reply-To: <1501595026-32368-1-git-send-email-tariqt@mellanox.com>
From: Jack Morgenstein <jackm@dev.mellanox.co.il>
The cited commit introduced the following new enum value in file
include/linux/mlx4/device.h:
QUERY_DEV_CAP_DIAG_RPRT_PER_PORT
However, it failed to introduce a corresponding entry in function
dump_dev_cap_flags2() for outputting a line in the message log
when this capability bit is set.
The change here fixes that omission.
Fixes: c7c122ed67e4 ("net/mlx4: Add diagnostic counters capability bit")
Reported-by: Mukesh Kacker <mukesh.kacker@oracle.com>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 7c9502bae1cc..041c0ed65929 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -159,6 +159,7 @@ static void dump_dev_cap_flags2(struct mlx4_dev *dev, u64 flags)
[32] = "Loopback source checks support",
[33] = "RoCEv2 support",
[34] = "DMFS Sniffer support (UC & MC)",
+ [35] = "Diag counters per port",
[36] = "QinQ VST mode support",
[37] = "sl to vl mapping table change event support",
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 1/4] net/mlx4_en: Fix wrong indication of Wake-on-LAN (WoL) support
From: Tariq Toukan @ 2017-08-01 13:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Inbar Karmy, Tariq Toukan
In-Reply-To: <1501595026-32368-1-git-send-email-tariqt@mellanox.com>
From: Inbar Karmy <inbark@mellanox.com>
Currently when WoL is supported but disabled, ethtool reports:
"Supports Wake-on: d".
Fix the indication of Wol support, so that the indication
remains "g" all the time if the NIC supports WoL.
Tested:
As accepted, when NIC supports WoL- ethtool reports:
Supports Wake-on: g
Wake-on: d
when NIC doesn't support WoL- ethtool reports:
Supports Wake-on: d
Wake-on: d
Fixes: 14c07b1358ed ("mlx4: Wake on LAN support")
Signed-off-by: Inbar Karmy <inbark@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 15 ++++++++-------
drivers/net/ethernet/mellanox/mlx4/fw.c | 4 ++++
drivers/net/ethernet/mellanox/mlx4/fw.h | 1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 2 ++
include/linux/mlx4/device.h | 1 +
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index c751a1d434ad..3d4e4a5d00d1 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -223,6 +223,7 @@ static void mlx4_en_get_wol(struct net_device *netdev,
struct ethtool_wolinfo *wol)
{
struct mlx4_en_priv *priv = netdev_priv(netdev);
+ struct mlx4_caps *caps = &priv->mdev->dev->caps;
int err = 0;
u64 config = 0;
u64 mask;
@@ -235,24 +236,24 @@ static void mlx4_en_get_wol(struct net_device *netdev,
mask = (priv->port == 1) ? MLX4_DEV_CAP_FLAG_WOL_PORT1 :
MLX4_DEV_CAP_FLAG_WOL_PORT2;
- if (!(priv->mdev->dev->caps.flags & mask)) {
+ if (!(caps->flags & mask)) {
wol->supported = 0;
wol->wolopts = 0;
return;
}
+ if (caps->wol_port[priv->port])
+ wol->supported = WAKE_MAGIC;
+ else
+ wol->supported = 0;
+
err = mlx4_wol_read(priv->mdev->dev, &config, priv->port);
if (err) {
en_err(priv, "Failed to get WoL information\n");
return;
}
- if (config & MLX4_EN_WOL_MAGIC)
- wol->supported = WAKE_MAGIC;
- else
- wol->supported = 0;
-
- if (config & MLX4_EN_WOL_ENABLED)
+ if ((config & MLX4_EN_WOL_ENABLED) && (config & MLX4_EN_WOL_MAGIC))
wol->wolopts = WAKE_MAGIC;
else
wol->wolopts = 0;
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 37e84a59e751..c165f16623a9 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -764,6 +764,7 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
#define QUERY_DEV_CAP_CQ_TS_SUPPORT_OFFSET 0x3e
#define QUERY_DEV_CAP_MAX_PKEY_OFFSET 0x3f
#define QUERY_DEV_CAP_EXT_FLAGS_OFFSET 0x40
+#define QUERY_DEV_CAP_WOL_OFFSET 0x43
#define QUERY_DEV_CAP_FLAGS_OFFSET 0x44
#define QUERY_DEV_CAP_RSVD_UAR_OFFSET 0x48
#define QUERY_DEV_CAP_UAR_SZ_OFFSET 0x49
@@ -920,6 +921,9 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
MLX4_GET(ext_flags, outbox, QUERY_DEV_CAP_EXT_FLAGS_OFFSET);
MLX4_GET(flags, outbox, QUERY_DEV_CAP_FLAGS_OFFSET);
dev_cap->flags = flags | (u64)ext_flags << 32;
+ MLX4_GET(field, outbox, QUERY_DEV_CAP_WOL_OFFSET);
+ dev_cap->wol_port[1] = !!(field & 0x20);
+ dev_cap->wol_port[2] = !!(field & 0x40);
MLX4_GET(field, outbox, QUERY_DEV_CAP_RSVD_UAR_OFFSET);
dev_cap->reserved_uars = field >> 4;
MLX4_GET(field, outbox, QUERY_DEV_CAP_UAR_SZ_OFFSET);
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.h b/drivers/net/ethernet/mellanox/mlx4/fw.h
index 5343a0599253..b52ba01aa486 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.h
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.h
@@ -129,6 +129,7 @@ struct mlx4_dev_cap {
u32 dmfs_high_rate_qpn_range;
struct mlx4_rate_limit_caps rl_caps;
struct mlx4_port_cap port_cap[MLX4_MAX_PORTS + 1];
+ bool wol_port[MLX4_MAX_PORTS + 1];
};
struct mlx4_func_cap {
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index a27c9c13a36e..09b9bc17bce9 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -424,6 +424,8 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
dev->caps.stat_rate_support = dev_cap->stat_rate_support;
dev->caps.max_gso_sz = dev_cap->max_gso_sz;
dev->caps.max_rss_tbl_sz = dev_cap->max_rss_tbl_sz;
+ dev->caps.wol_port[1] = dev_cap->wol_port[1];
+ dev->caps.wol_port[2] = dev_cap->wol_port[2];
/* Save uar page shift */
if (!mlx4_is_slave(dev)) {
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index aad5d81dfb44..b54517c05e9a 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -620,6 +620,7 @@ struct mlx4_caps {
u32 dmfs_high_rate_qpn_base;
u32 dmfs_high_rate_qpn_range;
u32 vf_caps;
+ bool wol_port[MLX4_MAX_PORTS + 1];
struct mlx4_rate_limit_caps rl_caps;
};
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/4] mlx4 misc fixes
From: Tariq Toukan @ 2017-08-01 13:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan
Hi Dave,
This patchset contains misc bug fixes from the team
to the mlx4 Core and Eth drivers.
Patch 1 by Inbar fixes a wrong ethtool indication for Wake-on-LAN.
The other 3 patches by Jack add a missing capability description,
and fixes the off-by-1 misalignment for the following capabilities
descriptions.
Series generated against net commit:
cc75f8514db6 samples/bpf: fix bpf tunnel cleanup
Thanks,
Tariq.
Inbar Karmy (1):
net/mlx4_en: Fix wrong indication of Wake-on-LAN (WoL) support
Jack Morgenstein (3):
net/mlx4_core: Fix sl_to_vl_change bit offset in flags2 dump
net/mlx4_core: Fix namespace misalignment in QinQ VST support commit
net/mlx4_core: Fixes missing capability bit in flags2 capability dump
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 15 ++++++++-------
drivers/net/ethernet/mellanox/mlx4/fw.c | 9 +++++++--
drivers/net/ethernet/mellanox/mlx4/fw.h | 1 +
drivers/net/ethernet/mellanox/mlx4/main.c | 2 ++
include/linux/mlx4/device.h | 1 +
5 files changed, 19 insertions(+), 9 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v2 net-next 2/3] net: dsa: lan9303: define LAN9303_NUM_PORTS 3
From: Egil Hjelmeland @ 2017-08-01 13:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Juergen Borleis, kernel, vivien.didelot, f.fainelli, netdev,
linux-kernel
In-Reply-To: <20170801132728.GA23157@lunn.ch>
On 01. aug. 2017 15:27, Andrew Lunn wrote:
> On Tue, Aug 01, 2017 at 02:31:44PM +0200, Egil Hjelmeland wrote:
>> On 01. aug. 2017 13:49, Juergen Borleis wrote:
>>> Hi Egil,
>>>
>>> On Tuesday 01 August 2017 13:14:38 Egil Hjelmeland wrote:
>>>> Will be used instead of '3' in upcomming patches.
>>>>
>>>>
>>>> +#define LAN9303_NUM_PORTS 3
>>>> +
>>>
>>> Maybe we should put this macro into a shared location because
>>> in "net/dsa/tag_lan9303.c" there is already a "#define LAN9303_MAX_PORTS
>>> 3".
>>>
>>> jb
>>>
>>
>> Is there any suitable shared location for such driver specific
>> definitions?
>> I could change the name to LAN9303_MAX_PORTS so it the same.
>> Rhymes better with DSA_MAX_PORTS too.
>
> Hi Egil, Juergen
>
> The other tag drivers do:
>
> if (source_port >= ds->num_ports || !ds->ports[source_port].netdev)
> return NULL;
>
> or just
>
> if (!ds->ports[port].netdev)
> return NULL;
>
> The first version is the safest, since a malicious switch could return
> port 42, and you are accessing way off the end of ds->ports[]. It does
> however require you call dsa_switch_alloc() with the correct number of
> ports.
>
Sounds like a plan for a later patch, when changing to
dsa_switch_alloc(LAN9303_NUM_PORTS)
> Andrew
>
Egil
^ permalink raw reply
* Re: [PATCH v2 net-next 1/3] net: dsa: lan9303: Refactor lan9303_xxx_packet_processing()
From: Egil Hjelmeland @ 2017-08-01 13:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: vivien.didelot, f.fainelli, netdev, linux-kernel, kernel
In-Reply-To: <20170801133934.GB23157@lunn.ch>
On 01. aug. 2017 15:39, Andrew Lunn wrote:
>> @@ -704,7 +710,7 @@ static void lan9303_get_ethtool_stats(struct dsa_switch *ds, int port,
>> unsigned int u, poff;
>> int ret;
>>
>> - poff = port * 0x400;
>> + poff = LAN9303_SWITCH_PORT_REG(port, 0);
>>
>> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
>> ret = lan9303_read_switch_reg(chip,
>
> So the actual code is:
>
> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
> ret = lan9303_read_switch_reg(chip,
> lan9303_mib[u].offset + poff,
> ®);
>
> Could this be written as
>
> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
> ret = lan9303_read_switch_port(chip, port, lan9303_mib[u].offset, ®);
>
> It is then clear you are reading the statistics from a port register.
>
> Andrew
>
Yes it can. Since it is (insignificantly) less efficient, I
chose not to touch it. But I can do it if you like.
Egil
^ permalink raw reply
* Re: [PATCH v2 net-next 1/3] net: dsa: lan9303: Refactor lan9303_xxx_packet_processing()
From: Andrew Lunn @ 2017-08-01 14:02 UTC (permalink / raw)
To: Egil Hjelmeland; +Cc: vivien.didelot, f.fainelli, netdev, linux-kernel, kernel
In-Reply-To: <faf9e431-c5e4-7fcc-0341-6fc46e3561fb@egil-hjelmeland.no>
On Tue, Aug 01, 2017 at 03:50:14PM +0200, Egil Hjelmeland wrote:
> On 01. aug. 2017 15:39, Andrew Lunn wrote:
> >>@@ -704,7 +710,7 @@ static void lan9303_get_ethtool_stats(struct dsa_switch *ds, int port,
> >> unsigned int u, poff;
> >> int ret;
> >>- poff = port * 0x400;
> >>+ poff = LAN9303_SWITCH_PORT_REG(port, 0);
> >> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
> >> ret = lan9303_read_switch_reg(chip,
> >
> >So the actual code is:
> >
> > for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
> > ret = lan9303_read_switch_reg(chip,
> > lan9303_mib[u].offset + poff,
> > ®);
> >
> >Could this be written as
> >
> > for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
> > ret = lan9303_read_switch_port(chip, port, lan9303_mib[u].offset, ®);
> >
> >It is then clear you are reading the statistics from a port register.
> >
> > Andrew
> >
>
> Yes it can. Since it is (insignificantly) less efficient, I
> chose not to touch it. But I can do it if you like.
I doubt it is less efficient. The compiler has seen
lan9303_read_switch_port() and will probably inline it. So what the
optimiser gets to see is probably the same in both cases.
Try generating the assembler listing in both cases, and compare them
make drivers/net/dsa/lan9303-core.lst
Andrew
^ permalink raw reply
* Re: [PATCH RFC, iproute2] tc/mirred: Extend the mirred/redirect action to accept additional traffic class parameter
From: Roman Mashak @ 2017-08-01 14:02 UTC (permalink / raw)
To: Amritha Nambiar
Cc: stephen, netdev, alexander.h.duyck, kiran.patil,
sridhar.samudrala, mitch.a.williams, alexander.duyck,
neerav.parikh, carolyn.wyborny, jeffrey.t.kirsher
In-Reply-To: <150154805003.4819.12498976860683140342.stgit@anamdev.jf.intel.com>
Amritha Nambiar <amritha.nambiar@intel.com> writes:
[...]
> @@ -72,6 +73,8 @@ parse_direction(struct action_util *a, int *argc_p, char ***argv_p,
> struct tc_mirred p = {};
> struct rtattr *tail;
> char d[16] = {};
> + __u32 flags = 0;
> + __u8 tc;
>
> while (argc > 0) {
>
> @@ -142,6 +145,18 @@ parse_direction(struct action_util *a, int *argc_p, char ***argv_p,
> argc--;
> argv++;
>
> + if ((argc > 0) && (matches(*argv, "tc") == 0)) {
> + NEXT_ARG();
> + tc = atoi(*argv);
Probably better to use strtol() instead, somebody wants to specify hex
base, also it has stronger error checks.
> + if (tc >= MIRRED_TC_MAP_MAX) {
> + fprintf(stderr, "Invalid TC index\n");
> + return -1;
> + }
> + flags |= MIRRED_F_TC_MAP;
> + ok++;
> + argc--;
> + argv++;
> + }
> break;
>
> }
> @@ -193,6 +208,9 @@ parse_direction(struct action_util *a, int *argc_p, char ***argv_p,
> tail = NLMSG_TAIL(n);
> addattr_l(n, MAX_MSG, tca_id, NULL, 0);
> addattr_l(n, MAX_MSG, TCA_MIRRED_PARMS, &p, sizeof(p));
> + if (flags & MIRRED_F_TC_MAP)
> + addattr_l(n, MAX_MSG, TCA_MIRRED_TC_MAP,
> + &tc, sizeof(tc));
> tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
>
> *argc_p = argc;
> @@ -248,6 +266,7 @@ print_mirred(struct action_util *au, FILE * f, struct rtattr *arg)
> struct tc_mirred *p;
> struct rtattr *tb[TCA_MIRRED_MAX + 1];
> const char *dev;
> + __u8 *tc;
>
> if (arg == NULL)
> return -1;
> @@ -273,6 +292,11 @@ print_mirred(struct action_util *au, FILE * f, struct rtattr *arg)
> fprintf(f, "mirred (%s to device %s)", mirred_n2a(p->eaction), dev);
> print_action_control(f, " ", p->action, "");
>
> + if (tb[TCA_MIRRED_TC_MAP]) {
> + tc = RTA_DATA(tb[TCA_MIRRED_TC_MAP]);
> + fprintf(f, " tc %d", *tc);
'tc' is declared as __u8 so format should be %u
> + }
> +
> fprintf(f, "\n ");
> fprintf(f, "\tindex %u ref %d bind %d", p->index, p->refcnt,
> p->bindcnt);
^ permalink raw reply
* [PATCH net-next] tcp: tcp_data_queue() cleanup
From: Eric Dumazet @ 2017-08-01 14:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Westphal
From: Eric Dumazet <edumazet@google.com>
Commit c13ee2a4f03f ("tcp: reindent two spots after prequeue removal")
removed code in tcp_data_queue().
We can go a little farther, removing an always true test,
and removing initializers for fragstolen and eaten variables.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Florian Westphal <fw@strlen.de>
---
net/ipv4/tcp_input.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index af0a98d54b627a90d90fb9f1f2a600277c620559..df670d7ed98df1c108dc654cf446344ff9fdd4be 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4564,8 +4564,8 @@ int tcp_send_rcvq(struct sock *sk, struct msghdr *msg, size_t size)
static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
{
struct tcp_sock *tp = tcp_sk(sk);
- bool fragstolen = false;
- int eaten = -1;
+ bool fragstolen;
+ int eaten;
if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq) {
__kfree_skb(skb);
@@ -4588,12 +4588,11 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
/* Ok. In sequence. In window. */
queue_and_out:
- if (eaten < 0) {
- if (skb_queue_len(&sk->sk_receive_queue) == 0)
- sk_forced_mem_schedule(sk, skb->truesize);
- else if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
- goto drop;
- }
+ if (skb_queue_len(&sk->sk_receive_queue) == 0)
+ sk_forced_mem_schedule(sk, skb->truesize);
+ else if (tcp_try_rmem_schedule(sk, skb, skb->truesize))
+ goto drop;
+
eaten = tcp_queue_rcv(sk, skb, 0, &fragstolen);
tcp_rcv_nxt_update(tp, TCP_SKB_CB(skb)->end_seq);
if (skb->len)
^ permalink raw reply related
* Re: [PATCH net-next 01/11] net: dsa: make EEE ops optional
From: Andrew Lunn @ 2017-08-01 14:07 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20170731221719.16695-2-vivien.didelot@savoirfairelinux.com>
Hi Vivien
> @@ -646,38 +646,42 @@ static int dsa_slave_set_eee(struct net_device *dev, struct ethtool_eee *e)
> {
> struct dsa_slave_priv *p = netdev_priv(dev);
> struct dsa_switch *ds = p->dp->ds;
> - int ret;
> + int err = -ENODEV;
>
> - if (!ds->ops->set_eee)
> - return -EOPNOTSUPP;
> + if (ds->ops->set_eee) {
> + err = ds->ops->set_eee(ds, p->dp->index, p->phy, e);
> + if (err)
> + return err;
> + }
>
> - ret = ds->ops->set_eee(ds, p->dp->index, p->phy, e);
> - if (ret)
> - return ret;
> + if (p->phy) {
> + err = phy_ethtool_set_eee(p->phy, e);
> + if (err)
> + return err;
I don't think you need this if (err). You unconditionally return err
as you exit the function.
> + }
>
> - if (p->phy)
> - ret = phy_ethtool_set_eee(p->phy, e);
> -
> - return ret;
> + return err;
> }
>
> static int dsa_slave_get_eee(struct net_device *dev, struct ethtool_eee *e)
> {
> struct dsa_slave_priv *p = netdev_priv(dev);
> struct dsa_switch *ds = p->dp->ds;
> - int ret;
> + int err = -ENODEV;
>
> - if (!ds->ops->get_eee)
> - return -EOPNOTSUPP;
> + if (ds->ops->get_eee) {
> + err = ds->ops->get_eee(ds, p->dp->index, e);
> + if (err)
> + return err;
> + }
>
> - ret = ds->ops->get_eee(ds, p->dp->index, e);
> - if (ret)
> - return ret;
> + if (p->phy) {
> + err = phy_ethtool_get_eee(p->phy, e);
> + if (err)
> + return err;
Same here.
> + }
>
> - if (p->phy)
> - ret = phy_ethtool_get_eee(p->phy, e);
> -
> - return ret;
> + return err;
> }
>
> #ifdef CONFIG_NET_POLL_CONTROLLER
> --
> 2.13.3
>
^ permalink raw reply
* Re: [PATCH v3] ss: Enclose IPv6 address in brackets
From: Phil Sutter @ 2017-08-01 14:11 UTC (permalink / raw)
To: Florian Lehner; +Cc: netdev
In-Reply-To: <17aba498-3d75-2659-5fdc-4c95b0d214fa@der-flo.net>
On Tue, Aug 01, 2017 at 12:05:13PM +0200, Florian Lehner wrote:
[...]
> @@ -114,9 +114,13 @@ int addr64_n2a(__u64 addr, char *buff, size_t len);
> int af_bit_len(int af);
> int af_byte_len(int af);
>
> -const char *format_host_r(int af, int len, const void *addr,
> - char *buf, int buflen);
> -const char *format_host(int af, int lne, const void *addr);
> +const char *format_host_rb(int af, int len, const void *addr,
> + char *buf, int buflen, bool *resolved);
> +#define format_host_r(af, len, addr, buf, buflen) \
> + format_host_rb(af, len, addr, buf, buflen, NULL)
> +const char *format_host_b(int af, int lne, const void *addr, bool
> *resolved);
> +#define format_host(af, lne, addr) \
> + format_host_b(af, lne, addr, NULL)
> #define format_host_rta(af, rta) \
> format_host(af, RTA_PAYLOAD(rta), RTA_DATA(rta))
> const char *rt_addr_n2a_r(int af, int len, const void *addr,
> diff --git a/lib/utils.c b/lib/utils.c
> index 9aa3219..42c3bf5 100644
> --- a/lib/utils.c
> +++ b/lib/utils.c
> @@ -898,8 +898,8 @@ static const char *resolve_address(const void *addr,
> int len, int af)
> }
> #endif
>
> -const char *format_host_r(int af, int len, const void *addr,
> - char *buf, int buflen)
> +const char *format_host_rb(int af, int len, const void *addr,
> + char *buf, int buflen, bool *resolved)
> {
> #ifdef RESOLVE_HOSTNAMES
> if (resolve_hosts) {
> @@ -909,17 +909,20 @@ const char *format_host_r(int af, int len, const
> void *addr,
>
> if (len > 0 &&
> (n = resolve_address(addr, len, af)) != NULL)
> + {
> + *resolved = true;
> return n;
> + }
> }
> #endif
> return rt_addr_n2a_r(af, len, addr, buf, buflen);
> }
Did you test that? I guess calling format_host() will lead to
dereference of a NULL pointer.
Cheers, Phil
^ permalink raw reply
* RE: [PATCH net-next 00/10] net: l3mdev: Support for sockets bound to enslaved device
From: David Laight @ 2017-08-01 14:15 UTC (permalink / raw)
To: 'David Ahern', netdev@vger.kernel.org
In-Reply-To: <1501557206-27503-1-git-send-email-dsahern@gmail.com>
From: David Ahern
> Sent: 01 August 2017 04:13
...
> Existing code for socket lookups already pass in 6+ arguments. Rather
> than add another for the enslaved device index, the existing lookups
> are converted to use a new sk_lookup struct. From there, the enslaved
> device index becomes another element of the struct.
>
> Patch 1 introduces sk_lookup struct and helper.
I guess that socket lookup happens quite often!
Passing the lookup parameters in a structure might have a
measurable negative effect on performance - especially if the
structure isn't passed through to other functions.
Have you made any performance mearurements?
David
^ permalink raw reply
* [PATCH net] xfrm: fix null pointer dereference on state and tmpl sort
From: Koichiro Den @ 2017-08-01 14:21 UTC (permalink / raw)
To: netdev; +Cc: steffen.klassert, herbert, davem
Creating sub policy that matches the same outer flow as main policy does
leads to a null pointer dereference if the outer mode's family is ipv4.
For userspace compatibility, this patch just eliminates the crash i.e.,
does not introduce any new sorting rule, which would fruitlessly affect
all but the aforementioned case.
Signed-off-by: Koichiro Den <den@klaipeden.com>
---
net/xfrm/xfrm_state.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 6c0956d10db6..a792effdb0b5 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1620,6 +1620,7 @@ int
xfrm_tmpl_sort(struct xfrm_tmpl **dst, struct xfrm_tmpl **src, int n,
unsigned short family, struct net *net)
{
+ int i;
int err = 0;
struct xfrm_state_afinfo *afinfo = xfrm_state_get_afinfo(family);
if (!afinfo)
@@ -1628,6 +1629,9 @@ xfrm_tmpl_sort(struct xfrm_tmpl **dst, struct xfrm_tmpl **src, int n,
spin_lock_bh(&net->xfrm.xfrm_state_lock); /*FIXME*/
if (afinfo->tmpl_sort)
err = afinfo->tmpl_sort(dst, src, n);
+ else
+ for (i = 0; i < n; i++)
+ dst[i] = src[i];
spin_unlock_bh(&net->xfrm.xfrm_state_lock);
rcu_read_unlock();
return err;
@@ -1638,6 +1642,7 @@ int
xfrm_state_sort(struct xfrm_state **dst, struct xfrm_state **src, int n,
unsigned short family)
{
+ int i;
int err = 0;
struct xfrm_state_afinfo *afinfo = xfrm_state_get_afinfo(family);
struct net *net = xs_net(*src);
@@ -1648,6 +1653,9 @@ xfrm_state_sort(struct xfrm_state **dst, struct xfrm_state **src, int n,
spin_lock_bh(&net->xfrm.xfrm_state_lock);
if (afinfo->state_sort)
err = afinfo->state_sort(dst, src, n);
+ else
+ for (i = 0; i < n; i++)
+ dst[i] = src[i];
spin_unlock_bh(&net->xfrm.xfrm_state_lock);
rcu_read_unlock();
return err;
--
2.9.4
^ permalink raw reply related
* Re: [PATCH net 3/3] tcp: fix xmit timer to only be reset if data ACKed/SACKed
From: Neal Cardwell @ 2017-08-01 14:24 UTC (permalink / raw)
To: maowenan
Cc: David Miller, netdev@vger.kernel.org, Yuchung Cheng,
Nandita Dukkipati
In-Reply-To: <F95AC9340317A84688A5F0DF0246F3F202933A7F@DGGEMI512-MBX.china.huawei.com>
On Tue, Aug 1, 2017 at 8:20 AM, maowenan <maowenan@huawei.com> wrote:
> > + /* If needed, reset TLP/RTO timer; RACK may later override this. */
> [Mao Wenan] I have question about RACK, if there is no RACK feature
> in lower version, who can clear this flag:FLAG_SET_XMIT_TIMER?
In the comment, "this" is referring to the xmit timer. The comment is
referring to the fact that RACK (or similarly
tcp_pause_early_retransmit() in earlier kernels) can override the
value of the xmit timer set in tcp_set_xmit_timer(). The comment is
not claiming that RACK clears the FLAG_SET_XMIT_TIMER bit in "flag".
Note that "flag" is an argument to tcp_ack(). And while processing a
given incoming ACK, the callers of tcp_ack() pass in either 0 or one
or more constant bit flags. So FLAG_SET_XMIT_TIMER and all the other
bit flags are implicitly set to zero at the beginning of processing
each ACK.
neal
^ permalink raw reply
* Re: [PATCH net-next 10/11] net: dsa: mv88e6xxx: remove EEE support
From: Andrew Lunn @ 2017-08-01 14:28 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20170731221719.16695-11-vivien.didelot@savoirfairelinux.com>
On Mon, Jul 31, 2017 at 06:17:18PM -0400, Vivien Didelot wrote:
> The PHY's EEE settings are already accessed by the DSA layer through the
> Marvell PHY driver and there is nothing to be done for switch's MACs.
I'm confused, or missing something. Does not patch #1 mean that if the
DSA driver does not have a set_eee function, we always return -ENODEV
in slave.c?
There might be nothing to configure here, but some of the switches do
support EEE. So we need at least a NOP set_eee. Better still it should
return -ENODEV for those switches which don't actually support EEE,
and 0 for those that do?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 00/11] net: dsa: rework EEE support
From: Andrew Lunn @ 2017-08-01 14:31 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20170731221719.16695-1-vivien.didelot@savoirfairelinux.com>
On Mon, Jul 31, 2017 at 06:17:08PM -0400, Vivien Didelot wrote:
> EEE implies configuring the port's PHY and MAC of both ends of the wire.
>
> The current EEE support in DSA mixes PHY and MAC configuration, which is
> bad because PHYs must be configured through a proper PHY driver. The DSA
> switch operations for EEE are only meant for configuring the port's MAC,
> which are integrated in the Ethernet switch device.
>
> This patchset fixes the EEE support in qca8k driver, makes the DSA layer
> call phy_init_eee for all drivers, and remove the EEE support from the
> mv88e6xxx driver since the Marvell PHY driver should be enough for it.
Hi Vivien
Thanks for working on this. I like the general direction this takes,
moving the repeated code into slave.c
Andrew
^ permalink raw reply
* Re: [PATCH RFC 08/13] phylink: add phylink infrastructure
From: Andrew Lunn @ 2017-08-01 14:34 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0Qb-0007Lq-FJ@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:03:13PM +0100, Russell King wrote:
> The link between the ethernet MAC and its PHY has become more complex
> as the interface evolves. This is especially true with serdes links,
> where the part of the PHY is effectively integrated into the MAC.
>
> Serdes links can be connected to a variety of devices, including SFF
> modules soldered down onto the board with the MAC, a SFP cage with
> a hotpluggable SFP module which may contain a PHY or directly modulate
> the serdes signals onto optical media with or without a PHY, or even
> a classical PHY connection.
>
> Moreover, the negotiation information on serdes links comes in two
> varieties - SGMII mode, where the PHY provides its speed/duplex/flow
> control information to the MAC, and 1000base-X mode where both ends
> exchange their abilities and each resolve the link capabilities.
>
> This means we need a more flexible means to support these arrangements,
> particularly with the hotpluggable nature of SFP, where the PHY can
> be attached or detached after the network device has been brought up.
>
> Ethtool information can come from multiple sources:
> - we may have a PHY operating in either SGMII or 1000base-X mode, in
> which case we take ethtool/mii data directly from the PHY.
> - we may have a optical SFP module without a PHY, with the MAC
> operating in 1000base-X mode - the ethtool/mii data needs to come
> from the MAC.
> - we may have a copper SFP module with a PHY whic can't be accessed,
> which means we need to take ethtool/mii data from the MAC.
>
> Phylink aims to solve this by providing an intermediary between the
> MAC and PHY, providing a safe way for PHYs to be hotplugged, and
> allowing a SFP driver to reconfigure the serdes connection.
>
> Phylink also takes over support of fixed link connections, where the
> speed/duplex/flow control are fixed, but link status may be controlled
> by a GPIO signal. By avoiding the fixed-phy implementation, phylink
> can provide a faster response to link events: fixed-phy has to wait for
> phylib to operate its state machine, which can take several seconds.
> In comparison, phylink takes milliseconds.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH RFC 09/13] sfp: add sfp-bus to bridge between network devices and sfp cages
From: Andrew Lunn @ 2017-08-01 14:35 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1da0Qg-0007Lx-KY@rmk-PC.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:03:18PM +0100, Russell King wrote:
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net 2/3] tcp: enable xmit timer fix by having TLP use time when RTO should fire
From: Neal Cardwell @ 2017-08-01 14:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Netdev, Yuchung Cheng, Nandita Dukkipati
In-Reply-To: <1501572126.1876.31.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Aug 1, 2017 at 3:22 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2017-07-31 at 22:58 -0400, Neal Cardwell wrote:
>> @@ -2418,13 +2418,9 @@ bool tcp_schedule_loss_probe(struct sock *sk)
>> timeout = max_t(u32, timeout, msecs_to_jiffies(10));
>>
>> /* If RTO is shorter, just schedule TLP in its place. */
>
> I have hard time to read this comment.
>
> We are here trying to arm a timer based on TLP.
>
> If RTO is shorter, we'll arm the timer based on RTO instead of TLP.
>
> Is "If RTO is shorter, just schedule TLP in its place." really correct ?
>
> I suggest we reword the comment or simply get rid of it now the code is
> more obvious.
OK, how about:
/* If the RTO formula yields an earlier time, then use that time. */
We can also add a reference to the RACK/TLP Internet Draft at the top
of tcp_schedule_loss_probe().
Whatever wording we decide on, I am happy to send a patch for net-next
once this fix is merged into net-next.
neal
^ permalink raw reply
* Re: [PATCH RFC 00/13] phylink and sfp support
From: Andrew Lunn @ 2017-08-01 14:39 UTC (permalink / raw)
To: Russell King - ARM Linux, David Miller; +Cc: Florian Fainelli, netdev
In-Reply-To: <20170725140138.GK31807@n2100.armlinux.org.uk>
On Tue, Jul 25, 2017 at 03:01:39PM +0100, Russell King - ARM Linux wrote:
> Hi,
>
> This patch series introduces generic support for SFP sockets found on
> various Marvell based platforms. The idea here is to provide common
> SFP socket support which can be re-used by network drivers as
> appropriate, rather than each network driver having to re-implement
> SFP socket support.
There is a lot of code here, and i'm not really going to understand it
until i use it. I have a couple of boards with SFFs connected to
switches, so i will spend some time over the next month or so to make
DSA use phylink. As is usual, we can sort out any issues as we go
along.
David, if it still applies cleanly, can you add it to net-next?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] ss: Enclose IPv6 address in brackets
From: Stephen Hemminger @ 2017-08-01 14:41 UTC (permalink / raw)
To: David Laight; +Cc: 'Florian Lehner', netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00480ED@AcuExch.aculab.com>
On Tue, 1 Aug 2017 11:11:03 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
> From: Florian Lehner
> > Sent: 29 July 2017 13:29
> > This patch adds support for RFC2732 IPv6 address format with brackets
> > for the tool ss. So output for ss changes from
> > 2a00:1450:400a:804::200e:443 to [2a00:1450:400a:804::200e]:443 for IPv6
> > addresses with attached port number.
> >
> > Signed-off-by: Lehner Florian <dev@der-flo.net>
> > ---
> > misc/ss.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/misc/ss.c b/misc/ss.c
> > index 12763c9..db39c93 100644
> > --- a/misc/ss.c
> > +++ b/misc/ss.c
> > @@ -1059,7 +1059,11 @@ static void inet_addr_print(const inet_prefix *a,
> > int port, unsigned int ifindex
> > ap = format_host(AF_INET, 4, a->data);
> > }
> > } else {
> > - ap = format_host(a->family, 16, a->data);
> > + if (a->family == AF_INET6) {
> > + sprintf(buf, "[%s]", format_host(a->family, 16, a->data));
> > + } else {
> > + ap = format_host(a->family, 16, a->data);
> > + }
> > est_len = strlen(ap);
> ...
>
> There are some strange things going on with global variables if this works at all.
> The text form of the address is in buf[] in one path and *ap in the other.
>
> One option might be to call format_host() then use strchr(ap, ':')
> to add [] if the string contains any ':'.
>
> David
>
That sounds like a better solution.
Also what about IN6ADDR_ANY
^ permalink raw reply
* Re: [PATCH v2 net-next 1/3] net: dsa: lan9303: Refactor lan9303_xxx_packet_processing()
From: Egil Hjelmeland @ 2017-08-01 14:43 UTC (permalink / raw)
To: Andrew Lunn; +Cc: vivien.didelot, f.fainelli, netdev, linux-kernel, kernel
In-Reply-To: <20170801140203.GC23157@lunn.ch>
On 01. aug. 2017 16:02, Andrew Lunn wrote:
> On Tue, Aug 01, 2017 at 03:50:14PM +0200, Egil Hjelmeland wrote:
>> On 01. aug. 2017 15:39, Andrew Lunn wrote:
>>>> @@ -704,7 +710,7 @@ static void lan9303_get_ethtool_stats(struct dsa_switch *ds, int port,
>>>> unsigned int u, poff;
>>>> int ret;
>>>> - poff = port * 0x400;
>>>> + poff = LAN9303_SWITCH_PORT_REG(port, 0);
>>>> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
>>>> ret = lan9303_read_switch_reg(chip,
>>>
>>> So the actual code is:
>>>
>>> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
>>> ret = lan9303_read_switch_reg(chip,
>>> lan9303_mib[u].offset + poff,
>>> ®);
>>>
>>> Could this be written as
>>>
>>> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
>>> ret = lan9303_read_switch_port(chip, port, lan9303_mib[u].offset, ®);
>>>
>>> It is then clear you are reading the statistics from a port register.
>>>
>>> Andrew
>>>
>>
>> Yes it can. Since it is (insignificantly) less efficient, I
>> chose not to touch it. But I can do it if you like.
>
> I doubt it is less efficient. The compiler has seen
> lan9303_read_switch_port() and will probably inline it. So what the
> optimiser gets to see is probably the same in both cases.
>
> Try generating the assembler listing in both cases, and compare them
>
> make drivers/net/dsa/lan9303-core.lst
>
> Andrew
>
Thanks for the tips about generating assembler listing, can be useful
another time. But in this case I trust you :-)
And in this case it does not really matter, because its not in the
data path.
I did try to look at the listing. But I did not quite understand it.
Looks like it is doing both inlining and unrolling.
Anyway, you just decide how you like to have it in this series.
Egil
^ permalink raw reply
* Re: [RFC net-next] net ipv6: convert fib6_table rwlock to a percpu lock
From: Stephen Hemminger @ 2017-08-01 14:45 UTC (permalink / raw)
To: Shaohua Li; +Cc: netdev, davem, Kernel-team, Shaohua Li, Wei Wang
In-Reply-To: <20170801025704.fuhxll23d3eenwrz@kernel.org>
On Mon, 31 Jul 2017 19:57:04 -0700
Shaohua Li <shli@kernel.org> wrote:
> On Mon, Jul 31, 2017 at 04:10:07PM -0700, Stephen Hemminger wrote:
> > On Mon, 31 Jul 2017 10:18:57 -0700
> > Shaohua Li <shli@kernel.org> wrote:
> >
> > > From: Shaohua Li <shli@fb.com>
> > >
> > > In a syn flooding test, the fib6_table rwlock is a significant
> > > bottleneck. While converting the rwlock to rcu sounds straighforward,
> > > but is very challenging if it's possible. A percpu spinlock is quite
> > > trival for this problem since updating the routing table is a rare
> > > event. In my test, the server receives around 1.5 Mpps in syn flooding
> > > test without the patch in a dual sockets and 56-CPU system. With the
> > > patch, the server receives around 3.8Mpps, and perf report doesn't show
> > > the locking issue.
> > >
> > > Cc: Wei Wang <weiwan@google.com>
> >
> > You just reinvented brlock...
It was a long time ago (2.4) that brlock came in
https://lwn.net/Articles/378781/
I removed it in 2.5.64 or so.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: l3mdev: Support for sockets bound to enslaved device
From: David Ahern @ 2017-08-01 14:45 UTC (permalink / raw)
To: David Laight, netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD00482E4@AcuExch.aculab.com>
On 8/1/17 8:15 AM, David Laight wrote:
> From: David Ahern
>> Sent: 01 August 2017 04:13
> ...
>> Existing code for socket lookups already pass in 6+ arguments. Rather
>> than add another for the enslaved device index, the existing lookups
>> are converted to use a new sk_lookup struct. From there, the enslaved
>> device index becomes another element of the struct.
>>
>> Patch 1 introduces sk_lookup struct and helper.
>
> I guess that socket lookup happens quite often!
> Passing the lookup parameters in a structure might have a
> measurable negative effect on performance - especially if the
> structure isn't passed through to other functions.
>
> Have you made any performance mearurements?
Before patches:
IPv4
Test TCP_RR 23769.42 23862.59 23867.69 sum
71499.70 avg 23833
Test TCP_CRR 8649.29 8650.94 8661.24 sum
25961.47 avg 8653
Test UDP_RR 26935.38 26813.30 26747.88 sum
80496.56 avg 26832
IPv6
Test TCP_RR 24708.10 24629.43 24593.75 sum
73931.28 avg 24643
Test TCP_CRR 8432.82 8489.26 8474.82 sum
25396.90 avg 8465
Test UDP_RR 23607.57 23722.37 23713.80 sum
71043.74 avg 23681
#################################################################
After patches:
IPv4
Test TCP_RR 24204.41 23993.05 24129.18 sum
72326.64 avg 24108
Test TCP_CRR 8690.31 8630.12 8620.88 sum
25941.31 avg 8647
Test UDP_RR 26653.26 26725.76 26587.70 sum
79966.72 avg 26655
IPv6
Test TCP_RR 24807.54 24698.30 24849.84 sum
74355.68 avg 24785
Test TCP_CRR 8573.22 8640.02 8624.09 sum
25837.33 avg 8612
Test UDP_RR 23800.14 23747.01 23814.94 sum
71362.09 avg 23787
The middle columns are the results of each 30-second run and then the
average of the 3 is on the end.
^ 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