* [PATCHv2 net-next 11/11] net: dsa: mv88e6xxx: Move g1 stats code in global1.[ch]
From: Andrew Lunn @ 2016-11-21 22:27 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, netdev, Andrew Lunn
In-Reply-To: <1479767225-13789-1-git-send-email-andrew@lunn.ch>
Move the stats functions which access global 1 registers into
global1.c.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 54 +++----------------------------------
drivers/net/dsa/mv88e6xxx/global1.c | 33 ++++++++++++++++++++++-
drivers/net/dsa/mv88e6xxx/global1.h | 2 ++
3 files changed, 37 insertions(+), 52 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5f2193949f87..bada6465af59 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -780,23 +780,6 @@ static void mv88e6xxx_adjust_link(struct dsa_switch *ds, int port,
netdev_err(ds->ports[port].netdev, "failed to configure MAC\n");
}
-static int _mv88e6xxx_stats_wait(struct mv88e6xxx_chip *chip)
-{
- u16 val;
- int i, err;
-
- for (i = 0; i < 10; i++) {
- err = mv88e6xxx_g1_read(chip, GLOBAL_STATS_OP, &val);
- if (err)
- return err;
-
- if ((val & GLOBAL_STATS_OP_BUSY) == 0)
- return 0;
- }
-
- return -ETIMEDOUT;
-}
-
static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
{
if (!chip->info->ops->stats_snapshot)
@@ -805,37 +788,6 @@ static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
return chip->info->ops->stats_snapshot(chip, port);
}
-static void _mv88e6xxx_stats_read(struct mv88e6xxx_chip *chip,
- int stat, u32 *val)
-{
- u32 value;
- u16 reg;
- int err;
-
- *val = 0;
-
- err = mv88e6xxx_g1_write(chip, GLOBAL_STATS_OP,
- GLOBAL_STATS_OP_READ_CAPTURED | stat);
- if (err)
- return;
-
- err = _mv88e6xxx_stats_wait(chip);
- if (err)
- return;
-
- err = mv88e6xxx_g1_read(chip, GLOBAL_STATS_COUNTER_32, ®);
- if (err)
- return;
-
- value = reg << 16;
-
- err = mv88e6xxx_g1_read(chip, GLOBAL_STATS_COUNTER_01, ®);
- if (err)
- return;
-
- *val = value | reg;
-}
-
static struct mv88e6xxx_hw_stat mv88e6xxx_hw_stats[] = {
{ "in_good_octets", 8, 0x00, STATS_TYPE_BANK0, },
{ "in_bad_octets", 4, 0x02, STATS_TYPE_BANK0, },
@@ -928,9 +880,9 @@ static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,
/* fall through */
case STATS_TYPE_BANK0:
reg |= s->reg | histogram;
- _mv88e6xxx_stats_read(chip, reg, &low);
+ mv88e6xxx_g1_stats_read(chip, reg, &low);
if (s->sizeof_stat == 8)
- _mv88e6xxx_stats_read(chip, reg + 1, &high);
+ mv88e6xxx_g1_stats_read(chip, reg + 1, &high);
}
value = (((u64)high) << 16) | low;
return value;
@@ -2888,7 +2840,7 @@ static int mv88e6xxx_g1_setup(struct mv88e6xxx_chip *chip)
return err;
/* Wait for the flush to complete. */
- err = _mv88e6xxx_stats_wait(chip);
+ err = mv88e6xxx_g1_stats_wait(chip);
if (err)
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/global1.c b/drivers/net/dsa/mv88e6xxx/global1.c
index fda8b3c7adad..af860d26b091 100644
--- a/drivers/net/dsa/mv88e6xxx/global1.c
+++ b/drivers/net/dsa/mv88e6xxx/global1.c
@@ -53,7 +53,7 @@ int mv88e6390_g1_stats_set_histogram(struct mv88e6xxx_chip *chip)
/* Offset 0x1d: Statistics Operation 2 */
-static int mv88e6xxx_g1_stats_wait(struct mv88e6xxx_chip *chip)
+int mv88e6xxx_g1_stats_wait(struct mv88e6xxx_chip *chip)
{
return mv88e6xxx_g1_wait(chip, GLOBAL_STATS_OP, GLOBAL_STATS_OP_BUSY);
}
@@ -95,3 +95,34 @@ int mv88e6390_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
/* Wait for the snapshotting to complete. */
return mv88e6xxx_g1_stats_wait(chip);
}
+
+void mv88e6xxx_g1_stats_read(struct mv88e6xxx_chip *chip, int stat, u32 *val)
+{
+ u32 value;
+ u16 reg;
+ int err;
+
+ *val = 0;
+
+ err = mv88e6xxx_g1_write(chip, GLOBAL_STATS_OP,
+ GLOBAL_STATS_OP_READ_CAPTURED | stat);
+ if (err)
+ return;
+
+ err = mv88e6xxx_g1_stats_wait(chip);
+ if (err)
+ return;
+
+ err = mv88e6xxx_g1_read(chip, GLOBAL_STATS_COUNTER_32, ®);
+ if (err)
+ return;
+
+ value = reg << 16;
+
+ err = mv88e6xxx_g1_read(chip, GLOBAL_STATS_COUNTER_01, ®);
+ if (err)
+ return;
+
+ *val = value | reg;
+}
+
diff --git a/drivers/net/dsa/mv88e6xxx/global1.h b/drivers/net/dsa/mv88e6xxx/global1.h
index ffc9f45baad9..df3794cdbfb9 100644
--- a/drivers/net/dsa/mv88e6xxx/global1.h
+++ b/drivers/net/dsa/mv88e6xxx/global1.h
@@ -19,9 +19,11 @@
int mv88e6xxx_g1_read(struct mv88e6xxx_chip *chip, int reg, u16 *val);
int mv88e6xxx_g1_write(struct mv88e6xxx_chip *chip, int reg, u16 val);
int mv88e6xxx_g1_wait(struct mv88e6xxx_chip *chip, int reg, u16 mask);
+int mv88e6xxx_g1_stats_wait(struct mv88e6xxx_chip *chip);
int mv88e6xxx_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port);
int mv88e6320_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port);
int mv88e6390_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port);
int mv88e6390_g1_stats_set_histogram(struct mv88e6xxx_chip *chip);
+void mv88e6xxx_g1_stats_read(struct mv88e6xxx_chip *chip, int stat, u32 *val);
#endif /* _MV88E6XXX_GLOBAL1_H */
--
2.10.2
^ permalink raw reply related
* [PATCHv2 net-next 04/11] net: dsa: mv88e6xxx: Abstract stats_snapshot into ops structure
From: Andrew Lunn @ 2016-11-21 22:26 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, netdev, Andrew Lunn
In-Reply-To: <1479767225-13789-1-git-send-email-andrew@lunn.ch>
Taking a stats snapshot differs between same families. Abstract this
into an ops member. At the same time, move the code into global1.[ch],
since the registers are in the global1 range.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
v2:
Move code into global1.c
---
drivers/net/dsa/mv88e6xxx/chip.c | 37 +++++++++++++++++++++--------------
drivers/net/dsa/mv88e6xxx/global1.c | 27 +++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/global1.h | 2 ++
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 5 +++++
4 files changed, 56 insertions(+), 15 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 02d1b3529ee4..6e72877f125a 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -797,22 +797,12 @@ static int _mv88e6xxx_stats_wait(struct mv88e6xxx_chip *chip)
return -ETIMEDOUT;
}
-static int _mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
+static int mv88e6xxx_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
{
- int err;
-
- if (mv88e6xxx_6320_family(chip) || mv88e6xxx_6352_family(chip))
- port = (port + 1) << 5;
-
- /* Snapshot the hardware statistics counters for this port. */
- err = mv88e6xxx_g1_write(chip, GLOBAL_STATS_OP,
- GLOBAL_STATS_OP_CAPTURE_PORT |
- GLOBAL_STATS_OP_HIST_RX_TX | port);
- if (err)
- return err;
+ if (!chip->info->ops->stats_snapshot)
+ return -EOPNOTSUPP;
- /* Wait for the snapshotting to complete. */
- return _mv88e6xxx_stats_wait(chip);
+ return chip->info->ops->stats_snapshot(chip, port);
}
static void _mv88e6xxx_stats_read(struct mv88e6xxx_chip *chip,
@@ -1003,7 +993,7 @@ static void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds, int port,
mutex_lock(&chip->reg_lock);
- ret = _mv88e6xxx_stats_snapshot(chip, port);
+ ret = mv88e6xxx_stats_snapshot(chip, port);
if (ret < 0) {
mutex_unlock(&chip->reg_lock);
return;
@@ -3162,6 +3152,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -3171,6 +3162,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6123_ops = {
@@ -3180,6 +3172,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6131_ops = {
@@ -3189,6 +3182,7 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6161_ops = {
@@ -3198,6 +3192,7 @@ static const struct mv88e6xxx_ops mv88e6161_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6165_ops = {
@@ -3207,6 +3202,7 @@ static const struct mv88e6xxx_ops mv88e6165_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6171_ops = {
@@ -3217,6 +3213,7 @@ static const struct mv88e6xxx_ops mv88e6171_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6172_ops = {
@@ -3229,6 +3226,7 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6352_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6175_ops = {
@@ -3239,6 +3237,7 @@ static const struct mv88e6xxx_ops mv88e6175_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6176_ops = {
@@ -3251,6 +3250,7 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6352_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6185_ops = {
@@ -3260,6 +3260,7 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6xxx_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6190_ops = {
@@ -3302,6 +3303,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6352_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6290_ops = {
@@ -3323,6 +3325,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6321_ops = {
@@ -3334,6 +3337,7 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6350_ops = {
@@ -3344,6 +3348,7 @@ static const struct mv88e6xxx_ops mv88e6350_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6351_ops = {
@@ -3354,6 +3359,7 @@ static const struct mv88e6xxx_ops mv88e6351_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6185_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6352_ops = {
@@ -3366,6 +3372,7 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.port_set_duplex = mv88e6xxx_port_set_duplex,
.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
.port_set_speed = mv88e6352_port_set_speed,
+ .stats_snapshot = mv88e6320_g1_stats_snapshot,
};
static const struct mv88e6xxx_ops mv88e6390_ops = {
diff --git a/drivers/net/dsa/mv88e6xxx/global1.c b/drivers/net/dsa/mv88e6xxx/global1.c
index d358720b6c2d..47b507d4d163 100644
--- a/drivers/net/dsa/mv88e6xxx/global1.c
+++ b/drivers/net/dsa/mv88e6xxx/global1.c
@@ -32,3 +32,30 @@ int mv88e6xxx_g1_wait(struct mv88e6xxx_chip *chip, int reg, u16 mask)
{
return mv88e6xxx_wait(chip, chip->info->global1_addr, reg, mask);
}
+
+static int mv88e6xxx_g1_stats_wait(struct mv88e6xxx_chip *chip)
+{
+ return mv88e6xxx_g1_wait(chip, GLOBAL_STATS_OP, GLOBAL_STATS_OP_BUSY);
+}
+
+int mv88e6xxx_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
+{
+ int err;
+
+ /* Snapshot the hardware statistics counters for this port. */
+ err = mv88e6xxx_g1_write(chip, GLOBAL_STATS_OP,
+ GLOBAL_STATS_OP_CAPTURE_PORT |
+ GLOBAL_STATS_OP_HIST_RX_TX | port);
+ if (err)
+ return err;
+
+ /* Wait for the snapshotting to complete. */
+ return mv88e6xxx_g1_stats_wait(chip);
+}
+
+int mv88e6320_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port)
+{
+ port = (port + 1) << 5;
+
+ return mv88e6xxx_g1_stats_snapshot(chip, port);
+}
diff --git a/drivers/net/dsa/mv88e6xxx/global1.h b/drivers/net/dsa/mv88e6xxx/global1.h
index 62291e6fe3a3..0080a30733e8 100644
--- a/drivers/net/dsa/mv88e6xxx/global1.h
+++ b/drivers/net/dsa/mv88e6xxx/global1.h
@@ -19,5 +19,7 @@
int mv88e6xxx_g1_read(struct mv88e6xxx_chip *chip, int reg, u16 *val);
int mv88e6xxx_g1_write(struct mv88e6xxx_chip *chip, int reg, u16 val);
int mv88e6xxx_g1_wait(struct mv88e6xxx_chip *chip, int reg, u16 mask);
+int mv88e6xxx_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port);
+int mv88e6320_g1_stats_snapshot(struct mv88e6xxx_chip *chip, int port);
#endif /* _MV88E6XXX_GLOBAL1_H */
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index de179c59f5cf..7c61cf626e56 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -794,6 +794,11 @@ struct mv88e6xxx_ops {
* Use SPEED_UNFORCED for normal detection, SPEED_MAX for max value.
*/
int (*port_set_speed)(struct mv88e6xxx_chip *chip, int port, int speed);
+
+ /* Snapshot the statistics for a port. The statistics can then
+ * be read back a leisure but still with a consistent view.
+ */
+ int (*stats_snapshot)(struct mv88e6xxx_chip *chip, int port);
};
enum stat_type {
--
2.10.2
^ permalink raw reply related
* [PATCHv2 net-next 10/11] net: dsa: mv88e6xxx: Implement mv88e6390 get_stats
From: Andrew Lunn @ 2016-11-21 22:27 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, netdev, Andrew Lunn
In-Reply-To: <1479767225-13789-1-git-send-email-andrew@lunn.ch>
The mv88e6390 uses a different bit to select between bank0 and bank1
of the statistics. So implement an ops function for this, and pass the
selector bit to the generic stats read function. Also, the histogram
selection has moved for the mv88e6390, so abstract its selection as
well.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 39 +++++++++++++++++++++++++++--------
drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 3 ++-
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index ac99e5b0ea75..5f2193949f87 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -815,8 +815,7 @@ static void _mv88e6xxx_stats_read(struct mv88e6xxx_chip *chip,
*val = 0;
err = mv88e6xxx_g1_write(chip, GLOBAL_STATS_OP,
- GLOBAL_STATS_OP_READ_CAPTURED |
- GLOBAL_STATS_OP_HIST_RX_TX | stat);
+ GLOBAL_STATS_OP_READ_CAPTURED | stat);
if (err)
return;
@@ -901,7 +900,8 @@ static struct mv88e6xxx_hw_stat mv88e6xxx_hw_stats[] = {
static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,
struct mv88e6xxx_hw_stat *s,
- int port)
+ int port, u16 bank1_select,
+ u16 histogram)
{
u32 low;
u32 high = 0;
@@ -924,10 +924,10 @@ static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,
}
break;
case STATS_TYPE_BANK1:
- reg = GLOBAL_STATS_OP_BANK_1;
+ reg = bank1_select;
/* fall through */
case STATS_TYPE_BANK0:
- reg |= s->reg;
+ reg |= s->reg | histogram;
_mv88e6xxx_stats_read(chip, reg, &low);
if (s->sizeof_stat == 8)
_mv88e6xxx_stats_read(chip, reg + 1, &high);
@@ -1012,7 +1012,8 @@ static int mv88e6xxx_get_sset_count(struct dsa_switch *ds)
}
static void mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
- uint64_t *data, int types)
+ uint64_t *data, int types,
+ u16 bank1_select, u16 histogram)
{
struct mv88e6xxx_hw_stat *stat;
int i, j;
@@ -1020,7 +1021,9 @@ static void mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
stat = &mv88e6xxx_hw_stats[i];
if (stat->type & types) {
- data[j] = _mv88e6xxx_get_ethtool_stat(chip, stat, port);
+ data[j] = _mv88e6xxx_get_ethtool_stat(chip, stat, port,
+ bank1_select,
+ histogram);
j++;
}
}
@@ -1030,14 +1033,25 @@ static void mv88e6095_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
uint64_t *data)
{
return mv88e6xxx_stats_get_stats(chip, port, data,
- STATS_TYPE_BANK0 | STATS_TYPE_PORT);
+ STATS_TYPE_BANK0 | STATS_TYPE_PORT,
+ 0, GLOBAL_STATS_OP_HIST_RX_TX);
}
static void mv88e6320_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
uint64_t *data)
{
return mv88e6xxx_stats_get_stats(chip, port, data,
- STATS_TYPE_BANK0 | STATS_TYPE_BANK1);
+ STATS_TYPE_BANK0 | STATS_TYPE_BANK1,
+ GLOBAL_STATS_OP_BANK_1_BIT_9,
+ GLOBAL_STATS_OP_HIST_RX_TX);
+}
+
+static void mv88e6390_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data)
+{
+ return mv88e6xxx_stats_get_stats(chip, port, data,
+ STATS_TYPE_BANK0 | STATS_TYPE_BANK1,
+ GLOBAL_STATS_OP_BANK_1_BIT_10, 0);
}
static void mv88e6xxx_get_stats(struct mv88e6xxx_chip *chip, int port,
@@ -3390,6 +3404,7 @@ static const struct mv88e6xxx_ops mv88e6190_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_ops mv88e6190x_ops = {
@@ -3405,6 +3420,7 @@ static const struct mv88e6xxx_ops mv88e6190x_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_ops mv88e6191_ops = {
@@ -3420,6 +3436,7 @@ static const struct mv88e6xxx_ops mv88e6191_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_ops mv88e6240_ops = {
@@ -3452,6 +3469,7 @@ static const struct mv88e6xxx_ops mv88e6290_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_ops mv88e6320_ops = {
@@ -3546,6 +3564,7 @@ static const struct mv88e6xxx_ops mv88e6390_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_ops mv88e6390x_ops = {
@@ -3561,6 +3580,7 @@ static const struct mv88e6xxx_ops mv88e6390x_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_ops mv88e6391_ops = {
@@ -3576,6 +3596,7 @@ static const struct mv88e6xxx_ops mv88e6391_ops = {
.stats_set_histogram = mv88e6390_g1_stats_set_histogram,
.stats_get_sset_count = mv88e6320_stats_get_sset_count,
.stats_get_strings = mv88e6320_stats_get_strings,
+ .stats_get_stats = mv88e6390_stats_get_stats,
};
static const struct mv88e6xxx_info mv88e6xxx_table[] = {
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index a6a66eb3169b..9298faa5878b 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -296,7 +296,8 @@
#define GLOBAL_STATS_OP_HIST_RX ((1 << 10) | GLOBAL_STATS_OP_BUSY)
#define GLOBAL_STATS_OP_HIST_TX ((2 << 10) | GLOBAL_STATS_OP_BUSY)
#define GLOBAL_STATS_OP_HIST_RX_TX ((3 << 10) | GLOBAL_STATS_OP_BUSY)
-#define GLOBAL_STATS_OP_BANK_1 BIT(9)
+#define GLOBAL_STATS_OP_BANK_1_BIT_9 BIT(9)
+#define GLOBAL_STATS_OP_BANK_1_BIT_10 BIT(10)
#define GLOBAL_STATS_COUNTER_32 0x1e
#define GLOBAL_STATS_COUNTER_01 0x1f
--
2.10.2
^ permalink raw reply related
* [PATCHv2 net-next 05/11] net: dsa: mv88e6xxx: Add comment about family a device belongs to
From: Andrew Lunn @ 2016-11-21 22:26 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, netdev, Andrew Lunn
In-Reply-To: <1479767225-13789-1-git-send-email-andrew@lunn.ch>
Knowing the family of device belongs to helps with picking the ops
implementation which is appropriate to the device. So add a comment to
each structure of ops.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 6e72877f125a..2ed7fc996176 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3146,6 +3146,7 @@ static int mv88e6xxx_set_eeprom(struct dsa_switch *ds,
}
static const struct mv88e6xxx_ops mv88e6085_ops = {
+ /* MV88E6XXX_FAMILY_6097 */
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
@@ -3156,6 +3157,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
};
static const struct mv88e6xxx_ops mv88e6095_ops = {
+ /* MV88E6XXX_FAMILY_6095 */
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
@@ -3166,6 +3168,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
};
static const struct mv88e6xxx_ops mv88e6123_ops = {
+ /* MV88E6XXX_FAMILY_6165 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
@@ -3176,6 +3179,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
};
static const struct mv88e6xxx_ops mv88e6131_ops = {
+ /* MV88E6XXX_FAMILY_6185 */
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
@@ -3186,6 +3190,7 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
};
static const struct mv88e6xxx_ops mv88e6161_ops = {
+ /* MV88E6XXX_FAMILY_6165 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
@@ -3196,6 +3201,7 @@ static const struct mv88e6xxx_ops mv88e6161_ops = {
};
static const struct mv88e6xxx_ops mv88e6165_ops = {
+ /* MV88E6XXX_FAMILY_6165 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
@@ -3206,6 +3212,7 @@ static const struct mv88e6xxx_ops mv88e6165_ops = {
};
static const struct mv88e6xxx_ops mv88e6171_ops = {
+ /* MV88E6XXX_FAMILY_6351 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3217,6 +3224,7 @@ static const struct mv88e6xxx_ops mv88e6171_ops = {
};
static const struct mv88e6xxx_ops mv88e6172_ops = {
+ /* MV88E6XXX_FAMILY_6352 */
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -3230,6 +3238,7 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
};
static const struct mv88e6xxx_ops mv88e6175_ops = {
+ /* MV88E6XXX_FAMILY_6351 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3241,6 +3250,7 @@ static const struct mv88e6xxx_ops mv88e6175_ops = {
};
static const struct mv88e6xxx_ops mv88e6176_ops = {
+ /* MV88E6XXX_FAMILY_6352 */
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -3254,6 +3264,7 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
};
static const struct mv88e6xxx_ops mv88e6185_ops = {
+ /* MV88E6XXX_FAMILY_6185 */
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
@@ -3264,6 +3275,7 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
};
static const struct mv88e6xxx_ops mv88e6190_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3274,6 +3286,7 @@ static const struct mv88e6xxx_ops mv88e6190_ops = {
};
static const struct mv88e6xxx_ops mv88e6190x_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3284,6 +3297,7 @@ static const struct mv88e6xxx_ops mv88e6190x_ops = {
};
static const struct mv88e6xxx_ops mv88e6191_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3294,6 +3308,7 @@ static const struct mv88e6xxx_ops mv88e6191_ops = {
};
static const struct mv88e6xxx_ops mv88e6240_ops = {
+ /* MV88E6XXX_FAMILY_6352 */
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -3307,6 +3322,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
};
static const struct mv88e6xxx_ops mv88e6290_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3317,6 +3333,7 @@ static const struct mv88e6xxx_ops mv88e6290_ops = {
};
static const struct mv88e6xxx_ops mv88e6320_ops = {
+ /* MV88E6XXX_FAMILY_6320 */
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -3329,6 +3346,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
};
static const struct mv88e6xxx_ops mv88e6321_ops = {
+ /* MV88E6XXX_FAMILY_6321 */
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -3341,6 +3359,7 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
};
static const struct mv88e6xxx_ops mv88e6350_ops = {
+ /* MV88E6XXX_FAMILY_6351 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3352,6 +3371,7 @@ static const struct mv88e6xxx_ops mv88e6350_ops = {
};
static const struct mv88e6xxx_ops mv88e6351_ops = {
+ /* MV88E6XXX_FAMILY_6351 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3363,6 +3383,7 @@ static const struct mv88e6xxx_ops mv88e6351_ops = {
};
static const struct mv88e6xxx_ops mv88e6352_ops = {
+ /* MV88E6XXX_FAMILY_6352 */
.get_eeprom = mv88e6xxx_g2_get_eeprom16,
.set_eeprom = mv88e6xxx_g2_set_eeprom16,
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -3376,6 +3397,7 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
};
static const struct mv88e6xxx_ops mv88e6390_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3386,6 +3408,7 @@ static const struct mv88e6xxx_ops mv88e6390_ops = {
};
static const struct mv88e6xxx_ops mv88e6390x_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
@@ -3396,6 +3419,7 @@ static const struct mv88e6xxx_ops mv88e6390x_ops = {
};
static const struct mv88e6xxx_ops mv88e6391_ops = {
+ /* MV88E6XXX_FAMILY_6390 */
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
--
2.10.2
^ permalink raw reply related
* Re: [PATCH net-next] udp: avoid one cache line miss in recvmsg()
From: Eric Dumazet @ 2016-11-21 22:05 UTC (permalink / raw)
To: Paolo Abeni; +Cc: David Miller, netdev
In-Reply-To: <1479765680.8455.422.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2016-11-21 at 14:01 -0800, Eric Dumazet wrote:
> Tested-by: Paolo Abeni <pabeni@redhat.com>
>
> Thanks Paolo
>
> Note that udp6_recvmsg() hits the 3rd cache line of skb to access
> skb->protocol :
>
> is_udp4 = (skb->protocol == htons(ETH_P_IP));
>
> We might some trick to avoid this cache line miss.
Argh, ignore this.
net-next kernel has this field at offset 0xc0, so all is good (since
this 4th cache line contains other needed fields)
^ permalink raw reply
* Re: [PATCH net-next] udp: avoid one cache line miss in recvmsg()
From: Eric Dumazet @ 2016-11-21 22:01 UTC (permalink / raw)
To: Paolo Abeni; +Cc: David Miller, netdev
In-Reply-To: <1479764208.5596.0.camel@redhat.com>
On Mon, 2016-11-21 at 22:36 +0100, Paolo Abeni wrote:
> Nice catch, thank you Eric!
>
> This gives up to 8% speed-up in my performance test (wire speed udp flood
> with small packets)
>
> Tested-by: Paolo Abeni <pabeni@redhat.com>
Thanks Paolo
Note that udp6_recvmsg() hits the 3rd cache line of skb to access
skb->protocol :
is_udp4 = (skb->protocol == htons(ETH_P_IP));
We might some trick to avoid this cache line miss.
^ permalink raw reply
* Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver
From: Jason Gunthorpe @ 2016-11-21 21:39 UTC (permalink / raw)
To: Vishwanathapura, Niranjana
Cc: Doug Ledford, linux-rdma, netdev, Dennis Dalessandro
In-Reply-To: <20161121213017.GB67872@knc-06.sc.intel.com>
On Mon, Nov 21, 2016 at 01:30:17PM -0800, Vishwanathapura, Niranjana wrote:
> On Sat, Nov 19, 2016 at 12:04:45PM -0700, Jason Gunthorpe wrote:
> >On Fri, Nov 18, 2016 at 02:42:10PM -0800, Vishwanathapura, Niranjana wrote:
> >>+HFI-VNIC DRIVER
> >>+M: Dennis Dalessandro <dennis.dalessandro@intel.com>
> >>+M: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
> >>+L: linux-rdma@vger.kernel.org
> >>+S: Supported
> >>+F: drivers/infiniband/sw/intel/vnic
> >
> >This is either a net driver or a ULP, no idea why it should go in this
> >directory!?
> >
> >It sounds like an ethernet driver, so you should probably put it
> >there...
> >
>
> The hfi_vnic is an Ethernet driver. It is similar to ULP like ipoib, but
> instead it is Ethernet over Omni-path here.
> The VNIC Ethernet (hfi_vnic) driver encapsulates Ethernet packets in an
> Omni-path header.
> The hfi_vnic Ethernet driver do not access the HW. It interfaces with HFI1
> driver which sends/receives Omni-Path encapsulated Ethernet frames from HW.
> Also, the VNIC control path driver (VEMA) is an IB MAD agent which should be
> under drivers/infiniband/.. .
> Putting the VNIC Ethernet driver and the VNIC control driver together under
> a single module (hfi_vnic.ko) provided a simpler interface between them.
>
> So, we have put the driver under drivers/infiniband/sw/intel for two reasons:
> a) We have VNIC control driver (VEMA) which is an IB mad agent.
> b) hfi_vnic Ethernet driver is dependent on HFI1 driver for sending/receving
> Omni-path encapsulated Ethernet packets from HW.
Sounds like this driver belongs under net/ someplace to me.
NAK on drivers/infiniband/sw/ at least - that dir is only for HCA
drivers.
> >>+/* hfi_vnic_bus_init - initialize the hfi vnic bus drvier */
> >>+static int hfi_vnic_bus_init(void)
> >>+{
> >>+ int rc;
> >>+
> >>+ ida_init(&hfi_vnic_ctrl_ida);
> >>+ idr_init(&hfi_vnic_idr);
> >>+
> >>+ rc = bus_register(&hfi_vnic_bus);
> >
> >Why on earth do we need this? Didn't I give you enough grief for the
> >psm stuff and now you want to create an entire subystem hidden away!?
> >
> >Use some netlink scheme to control your vnic like the rest of the net
> >stack..
> >
>
> The hfi_vnic_bus is only abstracting the HW independent functionality (like
> Ethernet interface, encapsulation, IB MAD interface etc) with the HW
> dependent functionality (sending/receiving packets on the wire).
> Thus providing a cleaner interface between HW independent hfi_vnic Ethernet
> and Control drivers and the HW dependent HFI1 driver.
That doesn't explain anything, sound like you don't need it so get rid
of it.
> There is no other User interface here other than the standard Ethernet
> interface through network stack.
Good, then this isn't needed, because it doesn't provide a user interface.
> #ls /sys/bus/hfi_vnic_bus/devices/
> hfi_vnic_ctrl_00 /* control device for HFI instance 0 */
> hfi_vnic_00.01.00 /* first VNIC port on HFI instance 0, port 1 */
Jason
^ permalink raw reply
* Re: [PATCH net-next] udp: avoid one cache line miss in recvmsg()
From: Paolo Abeni @ 2016-11-21 21:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1479518283.8455.312.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, 2016-11-18 at 17:18 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> UDP_SKB_CB(skb)->partial_cov is located at offset 66 in skb,
> requesting a cold cache line being read in cpu cache.
>
> We can avoid this cache line miss for UDP sockets,
> as partial_cov has a meaning only for UDPLite.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/udp.c | 3 ++-
> net/ipv6/udp.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index e1fc0116e8d59d8185670c6e55d1219bde55610d..b949770fdc08398a10f3974505a50b2b4f4b2cf3 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1389,7 +1389,8 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
> * coverage checksum (UDP-Lite), do it before the copy.
> */
>
> - if (copied < ulen || UDP_SKB_CB(skb)->partial_cov || peeking) {
> + if (copied < ulen || peeking ||
> + (is_udplite && UDP_SKB_CB(skb)->partial_cov)) {
> checksum_valid = !udp_lib_checksum_complete(skb);
> if (!checksum_valid)
> goto csum_copy_err;
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 4f99417d9b401f2a65c7828e7d6b86d1d6161794..8fd4d89380b86c8630f7fd27ce4e9958497a2b89 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -363,7 +363,8 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
> * coverage checksum (UDP-Lite), do it before the copy.
> */
>
> - if (copied < ulen || UDP_SKB_CB(skb)->partial_cov || peeking) {
> + if (copied < ulen || peeking ||
> + (is_udplite && UDP_SKB_CB(skb)->partial_cov)) {
> checksum_valid = !udp_lib_checksum_complete(skb);
> if (!checksum_valid)
> goto csum_copy_err;
>
>
Nice catch, thank you Eric!
This gives up to 8% speed-up in my performance test (wire speed udp flood
with small packets)
Tested-by: Paolo Abeni <pabeni@redhat.com>
^ permalink raw reply
* Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver
From: Vishwanathapura, Niranjana @ 2016-11-21 21:30 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Doug Ledford, linux-rdma, netdev, Dennis Dalessandro
In-Reply-To: <20161119190445.GG22775@obsidianresearch.com>
On Sat, Nov 19, 2016 at 12:04:45PM -0700, Jason Gunthorpe wrote:
>On Fri, Nov 18, 2016 at 02:42:10PM -0800, Vishwanathapura, Niranjana wrote:
>> +HFI-VNIC DRIVER
>> +M: Dennis Dalessandro <dennis.dalessandro@intel.com>
>> +M: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
>> +L: linux-rdma@vger.kernel.org
>> +S: Supported
>> +F: drivers/infiniband/sw/intel/vnic
>
>This is either a net driver or a ULP, no idea why it should go in this
>directory!?
>
>It sounds like an ethernet driver, so you should probably put it
>there...
>
The hfi_vnic is an Ethernet driver. It is similar to ULP like ipoib, but
instead it is Ethernet over Omni-path here.
The VNIC Ethernet (hfi_vnic) driver encapsulates Ethernet packets in an
Omni-path header.
The hfi_vnic Ethernet driver do not access the HW. It interfaces with HFI1
driver which sends/receives Omni-Path encapsulated Ethernet frames from HW.
Also, the VNIC control path driver (VEMA) is an IB MAD agent which should be
under drivers/infiniband/.. .
Putting the VNIC Ethernet driver and the VNIC control driver together under a
single module (hfi_vnic.ko) provided a simpler interface between them.
So, we have put the driver under drivers/infiniband/sw/intel for two reasons:
a) We have VNIC control driver (VEMA) which is an IB mad agent.
b) hfi_vnic Ethernet driver is dependent on HFI1 driver for sending/receving
Omni-path encapsulated Ethernet packets from HW.
>> +/* hfi_vnic_bus_init - initialize the hfi vnic bus drvier */
>> +static int hfi_vnic_bus_init(void)
>> +{
>> + int rc;
>> +
>> + ida_init(&hfi_vnic_ctrl_ida);
>> + idr_init(&hfi_vnic_idr);
>> +
>> + rc = bus_register(&hfi_vnic_bus);
>
>Why on earth do we need this? Didn't I give you enough grief for the
>psm stuff and now you want to create an entire subystem hidden away!?
>
>Use some netlink scheme to control your vnic like the rest of the net
>stack..
>
The hfi_vnic_bus is only abstracting the HW independent functionality (like
Ethernet interface, encapsulation, IB MAD interface etc) with the HW dependent
functionality (sending/receiving packets on the wire).
Thus providing a cleaner interface between HW independent hfi_vnic Ethernet and
Control drivers and the HW dependent HFI1 driver.
There is no other User interface here other than the standard Ethernet
interface through network stack.
HFI1 driver creates VNIC devices on the hfi_vnic_bus as below and the hfi_vnic
Ethernet and Control drivers drive them.
#ls /sys/bus/hfi_vnic_bus/devices/
hfi_vnic_ctrl_00 /* control device for HFI instance 0 */
hfi_vnic_00.01.00 /* first VNIC port on HFI instance 0, port 1 */
hfi_vnic_00.01.01 /* second VNIC port on HFI instance 0, port 1 */
The design is as shown in the below diagram.
+-------------------+ +----------------------+
| | | Linux |
| IB MAD | | Network |
| | | Stack |
+-------------------+ +----------------------+
| |
| |
+--------------------------------------------+
| |
| HFI VNIC Module |
| (HFI VNIC Netdev and EMA drivers) |
| (HW independent) |
+--------------------------------------------+
|
|
+--------------------------------------------+
| HFI VNIC Bus |
+--------------------------------------------+
|
|
+--------------------------------------------+
| |
| HFI1 Driver with VNIC support |
| (HW dependent) |
+--------------------------------------------+
Niranjana
>Jason
^ permalink raw reply
* [stable 4.4.y] ppp: defer netns reference release for ppp channel
From: Simon Arlott @ 2016-11-21 21:12 UTC (permalink / raw)
To: netdev
Please apply the following patch to linux-stable 4.4.y:
commit 205e1e255c479f3fd77446415706463b282f94e4
ppp: defer netns reference release for ppp channel
This is already present in 4.8.y and fixes an issue with ppp channels
that would otherwise cause a BUG() in ppp_pernet while a global ppp
mutex is held, preventing further ppp connections from being
established.
The issue is reproducible by having pppd use a PPPoE server that closes
new connections immediately (e.g. rp-pppoe "pppoe-server -q /bin/true").
--
Simon Arlott
^ permalink raw reply
* Re: [PATCH] net: ieee802154: constify ieee802154_ops structures
From: David Miller @ 2016-11-21 21:13 UTC (permalink / raw)
To: bhumirks
Cc: julia.lawall, michael.hennerich, aar, stefan, linux-wpan, netdev,
linux-kernel
In-Reply-To: <1479760214-32624-1-git-send-email-bhumirks@gmail.com>
From: Bhumika Goyal <bhumirks@gmail.com>
Date: Tue, 22 Nov 2016 02:00:14 +0530
> Declare the structure ieee802154_ops as const as it is only passed as an
> argument to the function ieee802154_alloc_hw. This argument is of type
> const struct ieee802154_ops *, so ieee80254_ops structures having this
> property can be declared as const.
> Done using Coccinelle:
...
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Applied.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN
From: Baicar, Tyler @ 2016-11-21 20:40 UTC (permalink / raw)
To: Neftin, Sasha, jeffrey.t.kirsher, intel-wired-lan, netdev,
linux-kernel, okaya, timur
In-Reply-To: <baeeb0a1-a454-6c81-59e9-3cec79a524a7@intel.com>
On 11/17/2016 6:31 AM, Neftin, Sasha wrote:
> On 11/13/2016 10:34 AM, Neftin, Sasha wrote:
>> On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
>>> Hello Sasha,
>>>
>>> On 11/9/2016 11:19 PM, Neftin, Sasha wrote:
>>>> On 11/9/2016 11:41 PM, Tyler Baicar wrote:
>>>>> Move IRQ free code so that it will happen regardless of the
>>>>> __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ
>>>>> if the __E1000_DOWN bit is cleared. This is not sufficient because
>>>>> it is possible for __E1000_DOWN to be set without releasing the IRQ.
>>>>> In such a situation, we will hit a kernel bug later in e1000_remove
>>>>> because the IRQ still has action since it was never freed. A
>>>>> secondary bus reset can cause this case to happen.
>>>>>
>>>>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>>>>> ---
>>>>> drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> index 7017281..36cfcb0 100644
>>>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> @@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>>>>> if (!test_bit(__E1000_DOWN, &adapter->state)) {
>>>>> e1000e_down(adapter, true);
>>>>> - e1000_free_irq(adapter);
>>>>> /* Link status message must follow this format */
>>>>> pr_info("%s NIC Link is Down\n", adapter->netdev->name);
>>>>> }
>>>>> + e1000_free_irq(adapter);
>>>>> +
>>>>> napi_disable(&adapter->napi);
>>>>> e1000e_free_tx_resources(adapter->tx_ring);
>>>>>
>>>> I would like not recommend insert this change. This change related
>>>> driver state machine, we afraid from lot of synchronization problem and
>>>> issues.
>>>> We need keep e1000_free_irq in loop and check for 'test_bit' ready.
>>> What do you mean here? There is no loop. If __E1000_DOWN is set then we
>>> will never free the IRQ.
>>>
>>>> Another point, does before execute secondary bus reset your SW back up
>>>> pcie configuration space as properly?
>>> After a secondary bus reset, the link needs to recover and go back to a
>>> working state after 1 second.
>>>
>>> From the callstack, the issue is happening while removing the endpoint
>>> from the system, before applying the secondary bus reset.
>>>
>>> The order of events is
>>> 1. remove the drivers
>>> 2. cause a secondary bus reset
>>> 3. wait 1 second
>> Actually, this is too much, usually link up in less than 100ms.You can
>> check Data Link Layer indication.
>>> 4. recover the link
>>>
>>> callstack:
>>> free_msi_irqs+0x6c/0x1a8
>>> pci_disable_msi+0xb0/0x148
>>> e1000e_reset_interrupt_capability+0x60/0x78
>>> e1000_remove+0xc8/0x180
>>> pci_device_remove+0x48/0x118
>>> __device_release_driver+0x80/0x108
>>> device_release_driver+0x2c/0x40
>>> pci_stop_bus_device+0xa0/0xb0
>>> pci_stop_bus_device+0x3c/0xb0
>>> pci_stop_root_bus+0x54/0x80
>>> acpi_pci_root_remove+0x28/0x64
>>> acpi_bus_trim+0x6c/0xa4
>>> acpi_device_hotplug+0x19c/0x3f4
>>> acpi_hotplug_work_fn+0x28/0x3c
>>> process_one_work+0x150/0x460
>>> worker_thread+0x50/0x4b8
>>> kthread+0xd4/0xe8
>>> ret_from_fork+0x10/0x50
>>>
>>> Thanks,
>>> Tyler
>>>
>> Hello Tyler,
>> Okay, we need consult more about this suggestion.
>> May I ask what is setup you run? Is there NIC or on board LAN? I would
>> like try reproduce this issue in our lab's too.
>> Also, is same issue observed with same scenario and others NIC's too?
>> Sasha
>> _______________________________________________
>> Intel-wired-lan mailing list
>> Intel-wired-lan@lists.osuosl.org
>> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>
> Hello Tyler,
> I see some in consistent implementation of __*_close methods in our
> drivers. Do you have any igb NIC to check if same problem persist there?
> Thanks,
> Sasha
Hello Sasha,
I couldn't find an igb NIC to test with, but I did find another e1000e
card that does not cause the same issue. That card is:
0004:01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
Network Connection
Subsystem: Intel Corporation Gigabit CT Desktop Adapter
Physical Slot: 5-1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 299
Region 0: Memory at c01001c0000 (32-bit, non-prefetchable)
[size=128K]
Region 1: Memory at c0100100000 (32-bit, non-prefetchable)
[size=512K]
Region 2: I/O ports at 1000 [size=32]
Region 3: Memory at c01001e0000 (32-bit, non-prefetchable)
[size=16K]
Expansion ROM at c0100180000 [disabled] [size=256K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000397f0040 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr+ TransPend-
LnkCap: Port #8, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Exit Latency L0s <128ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [a0] MSI-X: Enable- Count=5 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn-
ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 68-05-ca-ff-ff-29-47-34
Kernel driver in use: e1000e
Here are the kernel logs from first running the test on this card and
then running the test on the Intel 82571EB card that I originally found
the issue with (you can see the issue doesn't happen on this card but
does on the other):
[ 44.146749] ACPI: \_SB_.PCI0: Device has suffered a power fault
[ 44.155238] pcieport 0000:00:00.0: PCIe Bus Error:
severity=Uncorrected (Non-Fatal), type=Transaction Layer,
id=0000(Requester ID)
[ 44.166111] pcieport 0000:00:00.0: device [17cb:0400] error
status/mask=00004000/00400000
[ 44.174420] pcieport 0000:00:00.0: [14] Completion Timeout (First)
[ 44.401943] e1000e 0000:01:00.0 eth0: Timesync Tx Control register
not set as expected
[ 82.445586] pcieport 0002:00:00.0: PCIe Bus Error:
severity=Corrected, type=Physical Layer, id=0000(Receiver ID)
[ 82.454851] pcieport 0002:00:00.0: device [17cb:0400] error
status/mask=00000001/00006000
[ 82.463209] pcieport 0002:00:00.0: [ 0] Receiver Error
[ 82.469355] pcieport 0002:00:00.0: PCIe Bus Error:
severity=Uncorrected (Non-Fatal), type=Transaction Layer,
id=0000(Requester ID)
[ 82.481026] pcieport 0002:00:00.0: device [17cb:0400] error
status/mask=00004000/00400000
[ 82.489343] pcieport 0002:00:00.0: [14] Completion Timeout (First)
[ 82.504573] ACPI: \_SB_.PCI2: Device has suffered a power fault
[ 84.528036] kernel BUG at drivers/pci/msi.c:369!
I'm not sure why it reproduces on the 82571EB card and not the 82574L
card. The only obvious difference is there is no Reciever Error on the
82574L card.
If you have a patch fixing the inconsistencies you mentioned with the
__*_close methods I would certainly be willing to test it out!
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH] net: ieee802154: constify ieee802154_ops structures
From: Stefan Schmidt @ 2016-11-21 20:39 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, michael.hennerich, aar, linux-wpan,
netdev, linux-kernel
In-Reply-To: <1479760214-32624-1-git-send-email-bhumirks@gmail.com>
Hello.
On 21/11/16 21:30, Bhumika Goyal wrote:
> Declare the structure ieee802154_ops as const as it is only passed as an
> argument to the function ieee802154_alloc_hw. This argument is of type
> const struct ieee802154_ops *, so ieee80254_ops structures having this
> property can be declared as const.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct ieee802154_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> expression e1;
> @@
> ieee802154_alloc_hw(e1,&i@p)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> static
> +const
> struct ieee802154_ops i={...};
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct ieee802154_ops i;
>
> The before and after size details of the affected files are:
>
> text data bss dec hex filename
> 8669 1176 16 9861 2685 drivers/net/ieee802154/adf7242.o
> 8805 1048 16 9869 268d drivers/net/ieee802154/adf7242.o
>
> text data bss dec hex filename
> 7211 2296 32 9539 2543 drivers/net/ieee802154/atusb.o
> 7339 2160 32 9531 253b drivers/net/ieee802154/atusb.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> drivers/net/ieee802154/adf7242.c | 2 +-
> drivers/net/ieee802154/atusb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
> index 9fa7ac9..4ff4c7d 100644
> --- a/drivers/net/ieee802154/adf7242.c
> +++ b/drivers/net/ieee802154/adf7242.c
> @@ -874,7 +874,7 @@ static int adf7242_rx(struct adf7242_local *lp)
> return 0;
> }
>
> -static struct ieee802154_ops adf7242_ops = {
> +static const struct ieee802154_ops adf7242_ops = {
> .owner = THIS_MODULE,
> .xmit_sync = adf7242_xmit,
> .ed = adf7242_ed,
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index 1056ed1..322864a 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -567,7 +567,7 @@ static void atusb_stop(struct ieee802154_hw *hw)
> return 0;
> }
>
> -static struct ieee802154_ops atusb_ops = {
> +static const struct ieee802154_ops atusb_ops = {
> .owner = THIS_MODULE,
> .xmit_async = atusb_xmit,
> .ed = atusb_ed,
>
Acked-by: Stefan Schmidt <stefan@osg.samsung.com>
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH net-next v3 4/7] vxlan: improve vxlan route lookup checks.
From: Pravin Shelar @ 2016-11-21 20:34 UTC (permalink / raw)
To: Jiri Benc; +Cc: David Laight, netdev@vger.kernel.org
In-Reply-To: <20161117165950.6a8ed0d0@griffin>
On Thu, Nov 17, 2016 at 7:59 AM, Jiri Benc <jbenc@redhat.com> wrote:
> On Thu, 17 Nov 2016 10:17:01 +0000, David Laight wrote:
>> Worse than arbitrary, it adds 4 bytes of pad on 64bit systems.
>
> It does not, this is not a struct.
>
right.
After looking at the assembly code, it is clear that GCC and most of
modern compiler can reorder function variables for efficient storage.
^ permalink raw reply
* [PATCH] net: ieee802154: constify ieee802154_ops structures
From: Bhumika Goyal @ 2016-11-21 20:30 UTC (permalink / raw)
To: julia.lawall, michael.hennerich, aar, stefan, linux-wpan, netdev,
linux-kernel
Cc: Bhumika Goyal
Declare the structure ieee802154_ops as const as it is only passed as an
argument to the function ieee802154_alloc_hw. This argument is of type
const struct ieee802154_ops *, so ieee80254_ops structures having this
property can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct ieee802154_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
expression e1;
@@
ieee802154_alloc_hw(e1,&i@p)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct ieee802154_ops i={...};
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct ieee802154_ops i;
The before and after size details of the affected files are:
text data bss dec hex filename
8669 1176 16 9861 2685 drivers/net/ieee802154/adf7242.o
8805 1048 16 9869 268d drivers/net/ieee802154/adf7242.o
text data bss dec hex filename
7211 2296 32 9539 2543 drivers/net/ieee802154/atusb.o
7339 2160 32 9531 253b drivers/net/ieee802154/atusb.o
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/ieee802154/adf7242.c | 2 +-
drivers/net/ieee802154/atusb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index 9fa7ac9..4ff4c7d 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -874,7 +874,7 @@ static int adf7242_rx(struct adf7242_local *lp)
return 0;
}
-static struct ieee802154_ops adf7242_ops = {
+static const struct ieee802154_ops adf7242_ops = {
.owner = THIS_MODULE,
.xmit_sync = adf7242_xmit,
.ed = adf7242_ed,
diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
index 1056ed1..322864a 100644
--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -567,7 +567,7 @@ static void atusb_stop(struct ieee802154_hw *hw)
return 0;
}
-static struct ieee802154_ops atusb_ops = {
+static const struct ieee802154_ops atusb_ops = {
.owner = THIS_MODULE,
.xmit_async = atusb_xmit,
.ed = atusb_ed,
--
1.9.1
^ permalink raw reply related
* RE: [PATCH for-next 03/11] IB/hns: Optimize the logic of allocating memory using APIs
From: Salil Mehta @ 2016-11-21 20:20 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Huwei (Xavier),
oulijun, mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm,
Zhangping (ZP)
In-Reply-To: <20161121171423.GA23083-2ukJVAZIZ/Y@public.gmane.org>
> -----Original Message-----
> From: netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:netdev-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Leon Romanovsky
> Sent: Monday, November 21, 2016 5:14 PM
> To: Salil Mehta
> Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun;
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm;
> Zhangping (ZP)
> Subject: Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of
> allocating memory using APIs
>
> On Mon, Nov 21, 2016 at 04:12:38PM +0000, Salil Mehta wrote:
> > > -----Original Message-----
> > > From: Leon Romanovsky [mailto:leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> > > Sent: Wednesday, November 16, 2016 8:36 AM
> > > To: Salil Mehta
> > > Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun;
> > > mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm;
> > > Zhangping (ZP)
> > > Subject: Re: [PATCH for-next 03/11] IB/hns: Optimize the logic of
> > > allocating memory using APIs
> > >
> > > On Tue, Nov 15, 2016 at 03:52:46PM +0000, Salil Mehta wrote:
> > > > > -----Original Message-----
> > > > > From: Leon Romanovsky [mailto:leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> > > > > Sent: Wednesday, November 09, 2016 7:22 AM
> > > > > To: Salil Mehta
> > > > > Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org; Huwei (Xavier); oulijun;
> > > > > mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > > netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm;
> > > > > Zhangping (ZP)
> > > > > Subject: Re: [PATCH for-next 03/11] IB/hns: Optimize the logic
> of
> > > > > allocating memory using APIs
> > > > >
> > > > > On Fri, Nov 04, 2016 at 04:36:25PM +0000, Salil Mehta wrote:
> > > > > > From: "Wei Hu (Xavier)" <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > > >
> > > > > > This patch modified the logic of allocating memory using APIs
> in
> > > > > > hns RoCE driver. We used kcalloc instead of kmalloc_array and
> > > > > > bitmap_zero. And When kcalloc failed, call vzalloc to alloc
> > > > > > memory.
> > > > > >
> > > > > > Signed-off-by: Wei Hu (Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > > > Signed-off-by: Ping Zhang <zhangping5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > > > Signed-off-by: Salil Mehta <salil.mehta-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > > > ---
> > > > > > drivers/infiniband/hw/hns/hns_roce_mr.c | 15 ++++++++-----
> --
> > > > > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > > > b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > > > > index fb87883..d3dfb5f 100644
> > > > > > --- a/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > > > > +++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
> > > > > > @@ -137,11 +137,12 @@ static int hns_roce_buddy_init(struct
> > > > > hns_roce_buddy *buddy, int max_order)
> > > > > >
> > > > > > for (i = 0; i <= buddy->max_order; ++i) {
> > > > > > s = BITS_TO_LONGS(1 << (buddy->max_order - i));
> > > > > > - buddy->bits[i] = kmalloc_array(s, sizeof(long),
> > > > > GFP_KERNEL);
> > > > > > - if (!buddy->bits[i])
> > > > > > - goto err_out_free;
> > > > > > -
> > > > > > - bitmap_zero(buddy->bits[i], 1 << (buddy->max_order -
> > > i));
> > > > > > + buddy->bits[i] = kcalloc(s, sizeof(long),
> > > GFP_KERNEL);
> > > > > > + if (!buddy->bits[i]) {
> > > > > > + buddy->bits[i] = vzalloc(s * sizeof(long));
> > > > >
> > > > > I wonder, why don't you use directly vzalloc instead of kcalloc
> > > > > fallback?
> > > > As we know we will have physical contiguous pages if the kcalloc
> > > > call succeeds. This will give us a chance to have better
> performance
> > > > over the allocations which are just virtually contiguous through
> the
> > > > function vzalloc(). Therefore, later has only been used as a
> fallback
> > > > when our memory request cannot be entertained through kcalloc.
> > > >
> > > > Are you suggesting that there will not be much performance
> penalty
> > > > if we use just vzalloc ?
> > >
> > > Not exactly,
> > > I asked it, because we have similar code in our drivers and this
> > > construction looks strange to me.
> > >
> > > 1. If performance is critical, we will use kmalloc.
> > > 2. If performance is not critical, we will use vmalloc.
> > >
> > > But in this case, such construction shows me that we can live with
> > > vmalloc performance and kmalloc allocation are not really needed.
> > >
> > > In your specific case, I'm not sure that kcalloc will ever fail.
> > Performance is definitely critical here. Though, I agree this is bit
> > unusual way of memory allocation. In actual, we were encountering
> > memory alloc failures using kmalloc (if you see allocation amount
> > is on the higher side and is exponential) so we ended up using
> > vmalloc as fall back - It is very naïve allocation scheme.
>
> I understand it, we did the same, see our mlx5_vzalloc call.
> BTW, we used __GFP_NOWARN flag, which you should consider to use
> in your case too.
Ok. Will add this flag and refloat patch V3.
Thanks
>
> >
> > Maybe we need to rethink this allocation scheme part? Also, I can
> pull
> > back this particular patch for now or just live with vzalloc() till
> > we figure out proper solution to this?
>
> It is up to you, I don't think that you should drop it, AFAIK, there is
> no other proper solution.
Ok we will live with it for now and later maybe we can see how we can optimize
pre-allocation of physically contiguous memory.
Thanks for your suggestions!
Salil
>
> >
> > >
> > > Thanks
> > >
> > >
> > > >
> > > > >
> > > > > > + if (!buddy->bits[i])
> > > > > > + goto err_out_free;
> > > > > > + }
> > > > > > }
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC net-next 3/3] net: dsa: b53: Remove CPU port specific VLAN programming
From: Florian Fainelli @ 2016-11-21 19:09 UTC (permalink / raw)
To: netdev
Cc: davem, bridge, stephen, vivien.didelot, andrew, jiri, idosch,
Florian Fainelli
In-Reply-To: <20161121190925.14530-1-f.fainelli@gmail.com>
Now that DSA calls into the switch driver to program the CPU port's VLAN
attributes, we can get rid of the code that dealt with adding/removing
the CPU port to a downstream facing port VLAN membership.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 22 ++++++----------------
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 7717b19dc806..6577286a2721 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -951,7 +951,6 @@ static void b53_vlan_add(struct dsa_switch *ds, int port,
struct b53_device *dev = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
- unsigned int cpu_port = dev->cpu_port;
struct b53_vlan *vl;
u16 vid;
@@ -960,11 +959,11 @@ static void b53_vlan_add(struct dsa_switch *ds, int port,
b53_get_vlan_entry(dev, vid, vl);
- vl->members |= BIT(port) | BIT(cpu_port);
+ vl->members |= BIT(port);
if (untagged)
- vl->untag |= BIT(port) | BIT(cpu_port);
+ vl->untag |= BIT(port);
else
- vl->untag &= ~(BIT(port) | BIT(cpu_port));
+ vl->untag &= ~BIT(port);
b53_set_vlan_entry(dev, vid, vl);
b53_fast_age_vlan(dev, vid);
@@ -973,8 +972,6 @@ static void b53_vlan_add(struct dsa_switch *ds, int port,
if (pvid) {
b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
vlan->vid_end);
- b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(cpu_port),
- vlan->vid_end);
b53_fast_age_vlan(dev, vid);
}
}
@@ -984,7 +981,6 @@ static int b53_vlan_del(struct dsa_switch *ds, int port,
{
struct b53_device *dev = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
- unsigned int cpu_port = dev->cpu_port;
struct b53_vlan *vl;
u16 vid;
u16 pvid;
@@ -997,8 +993,6 @@ static int b53_vlan_del(struct dsa_switch *ds, int port,
b53_get_vlan_entry(dev, vid, vl);
vl->members &= ~BIT(port);
- if ((vl->members & BIT(cpu_port)) == BIT(cpu_port))
- vl->members = 0;
if (pvid == vid) {
if (is5325(dev) || is5365(dev))
@@ -1007,18 +1001,14 @@ static int b53_vlan_del(struct dsa_switch *ds, int port,
pvid = 0;
}
- if (untagged) {
+ if (untagged)
vl->untag &= ~(BIT(port));
- if ((vl->untag & BIT(cpu_port)) == BIT(cpu_port))
- vl->untag = 0;
- }
b53_set_vlan_entry(dev, vid, vl);
b53_fast_age_vlan(dev, vid);
}
b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), pvid);
- b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(cpu_port), pvid);
b53_fast_age_vlan(dev, pvid);
return 0;
@@ -1396,8 +1386,8 @@ static void b53_br_leave(struct dsa_switch *ds, int port)
b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
} else {
b53_get_vlan_entry(dev, pvid, vl);
- vl->members |= BIT(port) | BIT(dev->cpu_port);
- vl->untag |= BIT(port) | BIT(dev->cpu_port);
+ vl->members |= BIT(port);
+ vl->untag |= BIT(port);
b53_set_vlan_entry(dev, pvid, vl);
}
}
--
2.9.3
^ permalink raw reply related
* [RFC net-next 2/3] net: dsa: Propagate VLAN add/del to CPU port(s)
From: Florian Fainelli @ 2016-11-21 19:09 UTC (permalink / raw)
To: netdev
Cc: davem, bridge, stephen, vivien.didelot, andrew, jiri, idosch,
Florian Fainelli
In-Reply-To: <20161121190925.14530-1-f.fainelli@gmail.com>
Now that the bridge layer can call into switchdev to signal programming
requests targeting the bridge master device itself, allow the switch
drivers to implement separate programming of downstream and
upstream/management ports.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/slave.c | 45 +++++++++++++++++++++++++++++++++------------
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index d0c7bce88743..18288261b964 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -223,35 +223,30 @@ static int dsa_slave_set_mac_address(struct net_device *dev, void *a)
return 0;
}
-static int dsa_slave_port_vlan_add(struct net_device *dev,
+static int dsa_slave_port_vlan_add(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan,
struct switchdev_trans *trans)
{
- struct dsa_slave_priv *p = netdev_priv(dev);
- struct dsa_switch *ds = p->parent;
if (switchdev_trans_ph_prepare(trans)) {
if (!ds->ops->port_vlan_prepare || !ds->ops->port_vlan_add)
return -EOPNOTSUPP;
- return ds->ops->port_vlan_prepare(ds, p->port, vlan, trans);
+ return ds->ops->port_vlan_prepare(ds, port, vlan, trans);
}
- ds->ops->port_vlan_add(ds, p->port, vlan, trans);
+ ds->ops->port_vlan_add(ds, port, vlan, trans);
return 0;
}
-static int dsa_slave_port_vlan_del(struct net_device *dev,
+static int dsa_slave_port_vlan_del(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan)
{
- struct dsa_slave_priv *p = netdev_priv(dev);
- struct dsa_switch *ds = p->parent;
-
if (!ds->ops->port_vlan_del)
return -EOPNOTSUPP;
- return ds->ops->port_vlan_del(ds, p->port, vlan);
+ return ds->ops->port_vlan_del(ds, port, vlan);
}
static int dsa_slave_port_vlan_dump(struct net_device *dev,
@@ -465,8 +460,21 @@ static int dsa_slave_port_obj_add(struct net_device *dev,
const struct switchdev_obj *obj,
struct switchdev_trans *trans)
{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int port = p->port;
int err;
+ /* Here we may be called with an orig_dev which is different from dev,
+ * on purpose, to receive request coming from e.g the bridge master
+ * device. Although there are no network device associated with CPU/DSA
+ * ports, we may still have programming operation for these ports.
+ */
+ if (obj->orig_dev == p->bridge_dev) {
+ ds = ds->dst->ds[0];
+ port = ds->dst->cpu_port;
+ }
+
/* For the prepare phase, ensure the full set of changes is feasable in
* one go in order to signal a failure properly. If an operation is not
* supported, return -EOPNOTSUPP.
@@ -483,7 +491,7 @@ static int dsa_slave_port_obj_add(struct net_device *dev,
trans);
break;
case SWITCHDEV_OBJ_ID_PORT_VLAN:
- err = dsa_slave_port_vlan_add(dev,
+ err = dsa_slave_port_vlan_add(ds, port,
SWITCHDEV_OBJ_PORT_VLAN(obj),
trans);
break;
@@ -498,8 +506,21 @@ static int dsa_slave_port_obj_add(struct net_device *dev,
static int dsa_slave_port_obj_del(struct net_device *dev,
const struct switchdev_obj *obj)
{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int port = p->port;
int err;
+ /* Here we may be called with an orig_dev which is different from dev,
+ * on purpose, to receive request coming from e.g the bridge master
+ * device. Although there are no network device associated with CPU/DSA
+ * ports, we may still have programming operation for these ports.
+ */
+ if (obj->orig_dev == p->bridge_dev) {
+ ds = ds->dst->ds[0];
+ port = ds->dst->cpu_port;
+ }
+
switch (obj->id) {
case SWITCHDEV_OBJ_ID_PORT_FDB:
err = dsa_slave_port_fdb_del(dev,
@@ -509,7 +530,7 @@ static int dsa_slave_port_obj_del(struct net_device *dev,
err = dsa_slave_port_mdb_del(dev, SWITCHDEV_OBJ_PORT_MDB(obj));
break;
case SWITCHDEV_OBJ_ID_PORT_VLAN:
- err = dsa_slave_port_vlan_del(dev,
+ err = dsa_slave_port_vlan_del(ds, port,
SWITCHDEV_OBJ_PORT_VLAN(obj));
break;
default:
--
2.9.3
^ permalink raw reply related
* [RFC net-next 1/3] net: bridge: Allow bridge master device to configure switch CPU port
From: Florian Fainelli @ 2016-11-21 19:09 UTC (permalink / raw)
To: netdev
Cc: davem, bridge, stephen, vivien.didelot, andrew, jiri, idosch,
Florian Fainelli
In-Reply-To: <20161121190925.14530-1-f.fainelli@gmail.com>
An use case which is currently not possible with Linux bridges on top of
network switches is to configure the CPU port of the switch (inherently
presented to the user with a bridge master device) independently from
its downstream ports, with a different set of VLAN properties. The
reason as to why is that the switch driver will never get any call to
switchdev_port_obj_{add,del} with the obj->orig_dev set to the bridge
master device.
This allows CPU/management ports to e.g: receive all traffic as tagged,
whereas the downstream port may have different untagged VLAN settings.
The following happens now (assuming bridge master device is already
created):
bridge vlan add vid 2 dev port0 pvid untagged
-> port0 (e.g: switch port 0) gets programmed
-> CPU port gets programmed
bridge vlan add vid 2 dev br0 self
-> CPU port gets programmed
bridge vlan add vid 2 dev port0
-> port0 (switch port 0) gets programmed
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/bridge/br_vlan.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index b6de4f457161..b335d66d21db 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -228,7 +228,9 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
err = __vlan_vid_add(dev, br, v->vid, flags);
if (err)
goto out;
+ }
+ if (p) {
/* need to work on the master vlan too */
if (flags & BRIDGE_VLAN_INFO_MASTER) {
err = br_vlan_add(br, v->vid, flags |
@@ -242,6 +244,14 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags)
goto out_filt;
v->brvlan = masterv;
v->stats = masterv->stats;
+
+ /* Propagate the VLAN flags changes down to the underlying
+ * hardware, which may have to reconfigure the physical port
+ * associated with the bridge (e.g: CPU/management port)
+ */
+ err = __vlan_vid_add(br->dev, br, v->vid, flags);
+ if (err)
+ goto out_filt;
}
/* Add the dev mac and count the vlan only if it's usable */
@@ -287,19 +297,25 @@ static int __vlan_del(struct net_bridge_vlan *v)
struct net_bridge_vlan *masterv = v;
struct net_bridge_vlan_group *vg;
struct net_bridge_port *p = NULL;
+ struct net_device *dev;
+ struct net_bridge *br;
int err = 0;
if (br_vlan_is_master(v)) {
- vg = br_vlan_group(v->br);
+ br = v->br;
+ vg = br_vlan_group(br);
+ dev = v->br->dev;
} else {
p = v->port;
+ br = p->br;
+ dev = p->dev;
vg = nbp_vlan_group(v->port);
masterv = v->brvlan;
}
__vlan_delete_pvid(vg, v->vid);
- if (p) {
- err = __vlan_vid_del(p->dev, p->br, v->vid);
+ if (p || br_vlan_is_master(v)) {
+ err = __vlan_vid_del(dev, br, v->vid);
if (err)
goto out;
}
@@ -568,6 +584,12 @@ int br_vlan_add(struct net_bridge *br, u16 vid, u16 flags)
vg->num_vlans++;
}
__vlan_add_flags(vlan, flags);
+
+ /* Propagate the VLAN flags changes down to the underlying
+ * hardware, which may have to reconfigure the physical port
+ * associated with the bridge (e.g: CPU/management port)
+ */
+ __vlan_vid_add(br->dev, br, vlan->vid, flags);
return 0;
}
--
2.9.3
^ permalink raw reply related
* [RFC net-next 0/3] net: bridge: Allow CPU port configuration
From: Florian Fainelli @ 2016-11-21 19:09 UTC (permalink / raw)
To: netdev
Cc: davem, bridge, stephen, vivien.didelot, andrew, jiri, idosch,
Florian Fainelli
Hi all,
This patch series allows using the bridge master interface to configure
an Ethernet switch port's CPU/management port with different VLAN attributes than
those of the bridge downstream ports/members.
Jiri, Ido, Andrew, Vivien, please review the impact on mlxsw and mv88e6xxx, I
tested this with b53 and a mockup DSA driver.
Open questions:
- if we have more than one bridge on top of a physical switch, the driver
should keep track of that and verify that we are not going to change
the CPU port VLAN attributes in a way that results in incompatible settings
to be applied
- if the default behavior is to have all VLANs associated with the CPU port
be ingressing/egressing tagged to the CPU, is this really useful?
Florian Fainelli (3):
net: bridge: Allow bridge master device to configure switch CPU port
net: dsa: Propagate VLAN add/del to CPU port(s)
net: dsa: b53: Remove CPU port specific VLAN programming
drivers/net/dsa/b53/b53_common.c | 22 ++++++--------------
net/bridge/br_vlan.c | 28 ++++++++++++++++++++++---
net/dsa/slave.c | 45 +++++++++++++++++++++++++++++-----------
3 files changed, 64 insertions(+), 31 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] geneve: Use LWT more effectively.
From: David Miller @ 2016-11-21 19:06 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1479754981-17600-1-git-send-email-pshelar@ovn.org>
From: Pravin B Shelar <pshelar@ovn.org>
Date: Mon, 21 Nov 2016 11:02:57 -0800
> Following patch series make use of geneve LWT code path for
> geneve netdev type of device.
> This allows us to simplify geneve module without changing any
> functionality.
>
> v2-v3:
> Rebase against latest net-next.
>
> v1-v2:
> Fix warning reported by kbuild test robot.
Series applied, thanks Pravin.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] geneve: Use LWT more effectively.
From: Pravin Shelar @ 2016-11-21 19:03 UTC (permalink / raw)
To: David Miller; +Cc: Linux Kernel Network Developers
In-Reply-To: <20161121.112853.596026767987561055.davem@davemloft.net>
On Mon, Nov 21, 2016 at 8:28 AM, David Miller <davem@davemloft.net> wrote:
> From: Pravin B Shelar <pshelar@ovn.org>
> Date: Fri, 18 Nov 2016 18:10:07 -0800
>
>> Following patch series make use of geneve LWT code path for
>> geneve netdev type of device.
>> This allows us to simplify geneve module.
>>
>> v1-v2:
>> Fix warning reported by kbuild test robot.
>
> This doesn't apply cleanly to net-next, please respin.
>
Sure. I have posted updated series.
Thanks.
^ permalink raw reply
* [PATCH net-next v3 3/4] geneve: Remove redundant socket checks.
From: Pravin B Shelar @ 2016-11-21 19:03 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar
In-Reply-To: <1479754981-17600-1-git-send-email-pshelar@ovn.org>
Geneve already has check for device socket in route
lookup function. So no need to check it in xmit
function.
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
---
drivers/net/geneve.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 2cd5c41..633bb44 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -785,14 +785,11 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
struct geneve_sock *gs4 = rcu_dereference(geneve->sock4);
const struct ip_tunnel_key *key = &info->key;
struct rtable *rt;
- int err = -EINVAL;
struct flowi4 fl4;
__u8 tos, ttl;
__be16 sport;
__be16 df;
-
- if (!gs4)
- return err;
+ int err;
rt = geneve_get_v4_rt(skb, dev, &fl4, info);
if (IS_ERR(rt))
@@ -828,13 +825,10 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
struct geneve_sock *gs6 = rcu_dereference(geneve->sock6);
const struct ip_tunnel_key *key = &info->key;
struct dst_entry *dst = NULL;
- int err = -EINVAL;
struct flowi6 fl6;
__u8 prio, ttl;
__be16 sport;
-
- if (!gs6)
- return err;
+ int err;
dst = geneve_get_v6_dst(skb, dev, &fl6, info);
if (IS_ERR(dst))
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v3 4/4] geneve: Optimize geneve device lookup.
From: Pravin B Shelar @ 2016-11-21 19:03 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar
In-Reply-To: <1479754981-17600-1-git-send-email-pshelar@ovn.org>
Rather than comparing 64-bit tunnel-id, compare tunnel vni
which is 24-bit id. This also save conversion from vni
to tunnel id on each tunnel packet receive.
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
---
drivers/net/geneve.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 633bb44..d86d2f9 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -103,6 +103,17 @@ static void tunnel_id_to_vni(__be64 tun_id, __u8 *vni)
#endif
}
+static bool eq_tun_id_and_vni(u8 *tun_id, u8 *vni)
+{
+#ifdef __BIG_ENDIAN
+ return (vni[0] == tun_id[2]) &&
+ (vni[1] == tun_id[1]) &&
+ (vni[2] == tun_id[0]);
+#else
+ return !memcmp(vni, &tun_id[5], 3);
+#endif
+}
+
static sa_family_t geneve_get_sk_family(struct geneve_sock *gs)
{
return gs->sock->sk->sk_family;
@@ -111,7 +122,6 @@ static sa_family_t geneve_get_sk_family(struct geneve_sock *gs)
static struct geneve_dev *geneve_lookup(struct geneve_sock *gs,
__be32 addr, u8 vni[])
{
- __be64 id = vni_to_tunnel_id(vni);
struct hlist_head *vni_list_head;
struct geneve_dev *geneve;
__u32 hash;
@@ -120,7 +130,7 @@ static struct geneve_dev *geneve_lookup(struct geneve_sock *gs,
hash = geneve_net_vni_hash(vni);
vni_list_head = &gs->vni_list[hash];
hlist_for_each_entry_rcu(geneve, vni_list_head, hlist) {
- if (!memcmp(&id, &geneve->info.key.tun_id, sizeof(id)) &&
+ if (eq_tun_id_and_vni((u8 *)&geneve->info.key.tun_id, vni) &&
addr == geneve->info.key.u.ipv4.dst)
return geneve;
}
@@ -131,7 +141,6 @@ static struct geneve_dev *geneve_lookup(struct geneve_sock *gs,
static struct geneve_dev *geneve6_lookup(struct geneve_sock *gs,
struct in6_addr addr6, u8 vni[])
{
- __be64 id = vni_to_tunnel_id(vni);
struct hlist_head *vni_list_head;
struct geneve_dev *geneve;
__u32 hash;
@@ -140,7 +149,7 @@ static struct geneve_dev *geneve6_lookup(struct geneve_sock *gs,
hash = geneve_net_vni_hash(vni);
vni_list_head = &gs->vni_list[hash];
hlist_for_each_entry_rcu(geneve, vni_list_head, hlist) {
- if (!memcmp(&id, &geneve->info.key.tun_id, sizeof(id)) &&
+ if (eq_tun_id_and_vni((u8 *)&geneve->info.key.tun_id, vni) &&
ipv6_addr_equal(&addr6, &geneve->info.key.u.ipv6.dst))
return geneve;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v3 2/4] geneve: Merge ipv4 and ipv6 geneve_build_skb()
From: Pravin B Shelar @ 2016-11-21 19:02 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar
In-Reply-To: <1479754981-17600-1-git-send-email-pshelar@ovn.org>
There are minimal difference in building Geneve header
between ipv4 and ipv6 geneve tunnels. Following patch
refactors code to unify it.
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
---
drivers/net/geneve.c | 100 ++++++++++++++-------------------------------------
1 file changed, 26 insertions(+), 74 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 658531d..2cd5c41 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -630,67 +630,34 @@ static int geneve_stop(struct net_device *dev)
}
static void geneve_build_header(struct genevehdr *geneveh,
- __be16 tun_flags, u8 vni[3],
- u8 options_len, u8 *options)
+ const struct ip_tunnel_info *info)
{
geneveh->ver = GENEVE_VER;
- geneveh->opt_len = options_len / 4;
- geneveh->oam = !!(tun_flags & TUNNEL_OAM);
- geneveh->critical = !!(tun_flags & TUNNEL_CRIT_OPT);
+ geneveh->opt_len = info->options_len / 4;
+ geneveh->oam = !!(info->key.tun_flags & TUNNEL_OAM);
+ geneveh->critical = !!(info->key.tun_flags & TUNNEL_CRIT_OPT);
geneveh->rsvd1 = 0;
- memcpy(geneveh->vni, vni, 3);
+ tunnel_id_to_vni(info->key.tun_id, geneveh->vni);
geneveh->proto_type = htons(ETH_P_TEB);
geneveh->rsvd2 = 0;
- memcpy(geneveh->options, options, options_len);
+ ip_tunnel_info_opts_get(geneveh->options, info);
}
-static int geneve_build_skb(struct rtable *rt, struct sk_buff *skb,
- __be16 tun_flags, u8 vni[3], u8 opt_len, u8 *opt,
- bool xnet)
-{
- bool udp_sum = !!(tun_flags & TUNNEL_CSUM);
- struct genevehdr *gnvh;
- int min_headroom;
- int err;
-
- skb_scrub_packet(skb, xnet);
-
- min_headroom = LL_RESERVED_SPACE(rt->dst.dev) + rt->dst.header_len
- + GENEVE_BASE_HLEN + opt_len + sizeof(struct iphdr);
- err = skb_cow_head(skb, min_headroom);
- if (unlikely(err))
- goto free_rt;
-
- err = udp_tunnel_handle_offloads(skb, udp_sum);
- if (err)
- goto free_rt;
-
- gnvh = (struct genevehdr *)__skb_push(skb, sizeof(*gnvh) + opt_len);
- geneve_build_header(gnvh, tun_flags, vni, opt_len, opt);
-
- skb_set_inner_protocol(skb, htons(ETH_P_TEB));
- return 0;
-
-free_rt:
- ip_rt_put(rt);
- return err;
-}
-
-#if IS_ENABLED(CONFIG_IPV6)
-static int geneve6_build_skb(struct dst_entry *dst, struct sk_buff *skb,
- __be16 tun_flags, u8 vni[3], u8 opt_len, u8 *opt,
- bool xnet)
+static int geneve_build_skb(struct dst_entry *dst, struct sk_buff *skb,
+ const struct ip_tunnel_info *info,
+ bool xnet, int ip_hdr_len)
{
- bool udp_sum = !!(tun_flags & TUNNEL_CSUM);
+ bool udp_sum = !!(info->key.tun_flags & TUNNEL_CSUM);
struct genevehdr *gnvh;
int min_headroom;
int err;
+ skb_reset_mac_header(skb);
skb_scrub_packet(skb, xnet);
- min_headroom = LL_RESERVED_SPACE(dst->dev) + dst->header_len
- + GENEVE_BASE_HLEN + opt_len + sizeof(struct ipv6hdr);
+ min_headroom = LL_RESERVED_SPACE(dst->dev) + dst->header_len +
+ GENEVE_BASE_HLEN + info->options_len + ip_hdr_len;
err = skb_cow_head(skb, min_headroom);
if (unlikely(err))
goto free_dst;
@@ -699,9 +666,9 @@ static int geneve6_build_skb(struct dst_entry *dst, struct sk_buff *skb,
if (err)
goto free_dst;
- gnvh = (struct genevehdr *)__skb_push(skb, sizeof(*gnvh) + opt_len);
- geneve_build_header(gnvh, tun_flags, vni, opt_len, opt);
-
+ gnvh = (struct genevehdr *)__skb_push(skb, sizeof(*gnvh) +
+ info->options_len);
+ geneve_build_header(gnvh, info);
skb_set_inner_protocol(skb, htons(ETH_P_TEB));
return 0;
@@ -709,12 +676,11 @@ static int geneve6_build_skb(struct dst_entry *dst, struct sk_buff *skb,
dst_release(dst);
return err;
}
-#endif
static struct rtable *geneve_get_v4_rt(struct sk_buff *skb,
struct net_device *dev,
struct flowi4 *fl4,
- struct ip_tunnel_info *info)
+ const struct ip_tunnel_info *info)
{
bool use_cache = ip_tunnel_dst_cache_usable(skb, info);
struct geneve_dev *geneve = netdev_priv(dev);
@@ -738,7 +704,7 @@ static struct rtable *geneve_get_v4_rt(struct sk_buff *skb,
}
fl4->flowi4_tos = RT_TOS(tos);
- dst_cache = &info->dst_cache;
+ dst_cache = (struct dst_cache *)&info->dst_cache;
if (use_cache) {
rt = dst_cache_get_ip4(dst_cache, &fl4->saddr);
if (rt)
@@ -763,7 +729,7 @@ static struct rtable *geneve_get_v4_rt(struct sk_buff *skb,
static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
struct net_device *dev,
struct flowi6 *fl6,
- struct ip_tunnel_info *info)
+ const struct ip_tunnel_info *info)
{
bool use_cache = ip_tunnel_dst_cache_usable(skb, info);
struct geneve_dev *geneve = netdev_priv(dev);
@@ -789,7 +755,7 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
fl6->flowlabel = ip6_make_flowinfo(RT_TOS(prio),
info->key.label);
- dst_cache = &info->dst_cache;
+ dst_cache = (struct dst_cache *)&info->dst_cache;
if (use_cache) {
dst = dst_cache_get_ip6(dst_cache, &fl6->saddr);
if (dst)
@@ -812,7 +778,8 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb,
#endif
static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
- struct geneve_dev *geneve, struct ip_tunnel_info *info)
+ struct geneve_dev *geneve,
+ const struct ip_tunnel_info *info)
{
bool xnet = !net_eq(geneve->net, dev_net(geneve->dev));
struct geneve_sock *gs4 = rcu_dereference(geneve->sock4);
@@ -820,11 +787,9 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
struct rtable *rt;
int err = -EINVAL;
struct flowi4 fl4;
- u8 *opts = NULL;
__u8 tos, ttl;
__be16 sport;
__be16 df;
- u8 vni[3];
if (!gs4)
return err;
@@ -843,13 +808,7 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
}
df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
- tunnel_id_to_vni(key->tun_id, vni);
- if (info->options_len)
- opts = ip_tunnel_info_opts(info);
-
- skb_reset_mac_header(skb);
- err = geneve_build_skb(rt, skb, key->tun_flags, vni,
- info->options_len, opts, xnet);
+ err = geneve_build_skb(&rt->dst, skb, info, xnet, sizeof(struct iphdr));
if (unlikely(err))
return err;
@@ -862,7 +821,8 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
#if IS_ENABLED(CONFIG_IPV6)
static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
- struct geneve_dev *geneve, struct ip_tunnel_info *info)
+ struct geneve_dev *geneve,
+ const struct ip_tunnel_info *info)
{
bool xnet = !net_eq(geneve->net, dev_net(geneve->dev));
struct geneve_sock *gs6 = rcu_dereference(geneve->sock6);
@@ -870,10 +830,8 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
struct dst_entry *dst = NULL;
int err = -EINVAL;
struct flowi6 fl6;
- u8 *opts = NULL;
__u8 prio, ttl;
__be16 sport;
- u8 vni[3];
if (!gs6)
return err;
@@ -891,13 +849,7 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
ip_hdr(skb), skb);
ttl = key->ttl ? : ip6_dst_hoplimit(dst);
}
- tunnel_id_to_vni(key->tun_id, vni);
- if (info->options_len)
- opts = ip_tunnel_info_opts(info);
-
- skb_reset_mac_header(skb);
- err = geneve6_build_skb(dst, skb, key->tun_flags, vni,
- info->options_len, opts, xnet);
+ err = geneve_build_skb(dst, skb, info, xnet, sizeof(struct iphdr));
if (unlikely(err))
return err;
--
1.8.3.1
^ permalink raw reply related
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