* Re: [PATCH iproute2 v2] bridge: make mcast_flood description consistent
From: Stephen Hemminger @ 2019-02-21 22:48 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, Russell King
In-Reply-To: <20190220163357.25968-1-vivien.didelot@gmail.com>
On Wed, 20 Feb 2019 11:33:57 -0500
Vivien Didelot <vivien.didelot@gmail.com> wrote:
> This patch simply changes the description of the mcast_flood flag
> with "flood" instead of "be flooded with" to avoid confusion, and be
> consistent with the description of the flooding flag, which "Controls
> whether a given port will *flood* unicast traffic for which there is
> no FDB entry."
>
> At the same time, fix the documentation for the "flood" flag which
> is incorrectly described as "flooding on" or "flooding off".
>
> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
Applied
^ permalink raw reply
* Re: [PATCH iproute2] ss: fix compilation under glibc < 2.18
From: Stephen Hemminger @ 2019-02-21 22:49 UTC (permalink / raw)
To: Thomas De Schampheleire; +Cc: netdev, Thomas De Schampheleire
In-Reply-To: <CAAXf6LUAS5c-21P55gSG9-1yXZ_a8nEYU8GgeF=xgZQtmyohpQ@mail.gmail.com>
On Thu, 21 Feb 2019 08:43:08 +0100
Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:
> El jue., 21 feb. 2019 a las 2:53, Stephen Hemminger
> (<stephen@networkplumber.org>) escribió:
> >
> > On Wed, 20 Feb 2019 15:41:51 +0100
> > Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:
> >
> > > From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> > >
> > > Commit c759116a0b2b6da8df9687b0a40ac69050132c77 introduced support for
> > > AF_VSOCK. This define is only provided since glibc version 2.18, so
> > > compilation fails when using older toolchains.
> > >
> > > Provide the necessary definitions if needed.
> > >
> > > Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> >
> > Not sure why you would want new iproute2 with a 5 year old version of glibc?
> > Yes that means update your tool chain.
> >
>
> This problem is noticed for an embedded system. It has up-to-date
> applications and libraries (built via Buildroot) but the toolchain and
> kernel are supplied by the SoC vendor (in this case Marvell, formerly
> Cavium Networks). Unfortunately their toolchain is lagging behind and
> is still using glibc 2.16.
>
> I could handle this patch locally, but I think there may be other
> people in a similar situation which would benefit from an upstream
> fix.
OK applied, just don't want to keep lots of old cruft in the code
since it can lead to future suprise bugs.
^ permalink raw reply
* Re: [patch iproute2 v2] devlink: relax dpipe table show dependency on resources
From: Stephen Hemminger @ 2019-02-21 22:49 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, dsahern, mlxsw
In-Reply-To: <20190221105556.1315-1-jiri@resnulli.us>
On Thu, 21 Feb 2019 11:55:56 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Dpipe table show command has a depencency on getting resources.
> If resource get command is not supported by the driver, dpipe table
> show fails. However, resource is only additional information
> in dpipe table show output. So relax the dependency and let
> the dpipe tables be shown even if resources get command fails.
>
> Fixes: ead180274caf ("devlink: Add support for resource/dpipe relation")
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied
^ permalink raw reply
* Re: [PATCH v3 net-next 3/4] net: dsa: microchip: get port link status
From: Florian Fainelli @ 2019-02-21 22:55 UTC (permalink / raw)
To: Tristram.Ha, Sergio Paracuellos, Andrew Lunn, Pavel Machek
Cc: UNGLinuxDriver, netdev
In-Reply-To: <1550786597-591-4-git-send-email-Tristram.Ha@microchip.com>
On 2/21/19 2:03 PM, Tristram.Ha@microchip.com wrote:
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> Get port link status to know whether to read MIB counters when the link
> is going down. Add port_cleanup function to read MIB counters the last
> time as when the port is disabled the PHY is also powered down.
>
> Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
> ---
Some comments here and there again, not against a merge, but would be
nice to address in the future.
[snip]
> +void ksz_port_cleanup(struct ksz_device *dev, int port)
> +{
> + /* Read all MIB counters when the link is going down. */
> + if (dev->live_ports & (1 << port)) {
> + struct ksz_port *p = &dev->ports[port];
> +
> + p->read = true;
> + schedule_work(&dev->mib_read);
> + }
> +
> + /* Common code for port cleanup. */
> + dev->on_ports &= ~(1 << port);
It seems to be that dev->on_ports is a shorthand for a port is enabled
whether its link is up or down, which is equivalent to using:
!dsa_port_is_unused(ds, port)) unless I am mistaken about the intention
of the code.
In general you seem to be very prone to adding a lot of these
bookkeeping variables which just creates more opportunities for bugs to
creep in.
> + dev->live_ports &= ~(1 << port);
> +}
> +EXPORT_SYMBOL_GPL(ksz_port_cleanup);
> +
> void ksz_update_port_member(struct ksz_device *dev, int port)
> {
> struct ksz_port *p;
> @@ -156,6 +172,26 @@ int ksz_phy_write16(struct dsa_switch *ds, int addr, int reg, u16 val)
> }
> EXPORT_SYMBOL_GPL(ksz_phy_write16);
>
> +void ksz_adjust_link(struct dsa_switch *ds, int port,
> + struct phy_device *phydev)
> +{
> + struct ksz_device *dev = ds->priv;
> + struct ksz_port *p = &dev->ports[port];
> +
> + if (!phydev->link) {
> + /* Read all MIB counters when the link is going down. */
> + if (dev->live_ports & (1 << port)) {
> + p->read = true;
> + schedule_work(&dev->mib_read);
> + }
> + dev->live_ports &= ~(1 << port);
> + } else {
> + /* Remember which port is connected and active. */
> + dev->live_ports |= (1 << port) & dev->on_ports;
> + }
How about something simpler than this:
if (phydev->link != p->old_link) {
p->read = !!phydev->link;
schedule_work(&dev->mib_read);
}
This is also super racy because you schedule the workqueue without any
locking against the state machine which runs with the PHY device's mutex
held, so there is the possibility of the following happening:
Thread 0 Thread 1
ksz_adjust_link()
phydev->link = 0
schedule_work()
ksz_adjust_link()
p->read = true
mib_read_workqueue()
and so we don't read counters anymore. It is probably fine since this is
clearly entirely opportunistic and in order to minimize register bandwidth.
--
Florian
^ permalink raw reply
* Re: [PATCH] x86, retpolines: raise limit for generating indirect calls from switch-case
From: Daniel Borkmann @ 2019-02-21 22:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, Linux List Kernel Mailing, Netdev,
David S . Miller, Björn Töpel, Magnus Karlsson,
Jesper Dangaard Brouer, Alexei Starovoitov, Peter Zijlstra,
David Woodhouse, Andy Lutomirski, Borislav Petkov
In-Reply-To: <CAHk-=wgNfnC-oe7aJGgNWoTbssc0LPYK6FyR=6LO4_U_dsphbg@mail.gmail.com>
On 02/21/2019 11:27 PM, Linus Torvalds wrote:
> On Thu, Feb 21, 2019 at 2:20 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>
>> In case of gcc, this setting is controlled by case-values-threshold
>> which has an architecture global default that selects 4 or 5 (
>
> Ack. For retpoline, that's much too low.
>
> Patch looks sane, although it would be good to verify just which
> versions of gcc this works for. All versions with retpoline?
The feature was first added in gcc 4.7 [0], under "General Optimizer Improvements":
Support for a new parameter --param case-values-threshold=n was added to allow
users to control the cutoff between doing switch statements as a series of if
statements and using a jump table.
From what I can tell, original author (H.J. Lu) provided backports up to gcc 4.8
and distros seem to have pulled it from his github branch [1] as upstream gcc does
not handle backports for stable versions that old.
Thanks,
Daniel
[0] https://www.gnu.org/software/gcc/gcc-4.7/changes.html
[1] https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1749261
https://github.com/hjl-tools/gcc/tree/hjl/indirect/gcc-4_8-branch/master
^ permalink raw reply
* Re: [PATCH v3 net-next 2/4] net: dsa: microchip: add MIB counter reading support
From: Florian Fainelli @ 2019-02-21 23:01 UTC (permalink / raw)
To: Tristram.Ha, Sergio Paracuellos, Andrew Lunn, Pavel Machek
Cc: UNGLinuxDriver, netdev
In-Reply-To: <1550786597-591-3-git-send-email-Tristram.Ha@microchip.com>
On 2/21/19 2:03 PM, Tristram.Ha@microchip.com wrote:
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> Add background MIB counter reading support.
>
> Port MIB counters should only be read when there is link. Otherwise it is
> a waste of time as hardware never increases those counters. There are
> exceptions as some switches keep track of dropped counts no matter what.
Some minor comments below, none of them need to be addressed right now,
but it might be a good idea to do it at a later time.
[snip]
> +
> +static void mib_monitor(struct timer_list *t)
> +{
> + struct ksz_device *dev = from_timer(dev, t, mib_read_timer);
> + const struct dsa_port *dp;
> + struct net_device *netdev;
> + struct ksz_port_mib *mib;
> + struct ksz_port *p;
> + int i;
> +
> + mod_timer(&dev->mib_read_timer, jiffies + dev->mib_read_interval);
> +
> + /* Check which port needs to read MIB counters. */
> + for (i = 0; i < dev->mib_port_cnt; i++) {
> + p = &dev->ports[i];
> + if (!p->on)
> + continue;
Would not using dsa_port_is_unused() accomplish the same thing here?
Your setup function should not have enabled non-existent/connected to
the outside world ports anyway.
> + dp = dsa_to_port(dev->ds, i);
> + netdev = dp->slave;
> +
> + mib = &p->mib;
> + mutex_lock(&mib->cnt_mutex);
Have you built this with CONFIG_DEBUG_SLEEP_ATOMIC? timer executes in BH
context (atomic), you cannot hold a mutex here which would be allowed to
sleep.
> +
> + /* Read only dropped counters when link is not up. */
> + if (netdev && !netif_carrier_ok(netdev))> + mib->cnt_ptr = dev->reg_mib_cnt;
> + mutex_unlock(&mib->cnt_mutex);
> + p->read = true;
> + }
> + schedule_work(&dev->mib_read);
> +}
[snip]
> +
> int ksz_phy_read16(struct dsa_switch *ds, int addr, int reg)
> {
> struct ksz_device *dev = ds->priv;
> @@ -72,6 +167,26 @@ int ksz_sset_count(struct dsa_switch *ds, int port, int sset)
> }
> EXPORT_SYMBOL_GPL(ksz_sset_count);
>
> +void ksz_get_ethtool_stats(struct dsa_switch *ds, int port, uint64_t *buf)
> +{
> + const struct dsa_port *dp = dsa_to_port(ds, port);
> + struct ksz_device *dev = ds->priv;
> + struct net_device *netdev;
> + struct ksz_port_mib *mib;
> +
> + mib = &dev->ports[port].mib;
> + mutex_lock(&mib->cnt_mutex);
> +
> + /* Only read dropped counters if no link. */
> + netdev = dp->slave;
> + if (netdev && !netif_carrier_ok(netdev))
> + mib->cnt_ptr = dev->reg_mib_cnt;
The netdev is guaranteed to exist, otherwise you would not be in this
function, and we are executing with RTNL held, so the device can't
vanish under your feet.
[snip]
>
> +/* Modify from readx_poll_timeout in iopoll.h. */
> +#define ksz_pread_poll_timeout(op, dev, p, addr, val, cond, sleep_us, \
> + timeout_us) \
> +({ \
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> + might_sleep_if(sleep_us); \
> + for (;;) { \
> + op(dev, p, addr, &(val)); \
I don't think you need to create your own custom macro, which you seem
to need such that you can pass dev and p as arguments, instead you can
create a specific helper function, pass it down to op() as the "addr"
argument, since that is a macro that does not type checking at all. So
something like this:
struct ksz_read_ctx {
struct ksz_device *dev;
struct ksz_port *p;
u16 reg;
};
static int ksz_pread32_poll(struct ksz_read_ctx *ctx)
{
return ksz_pread32(ctx->dev, ctx->p, ctx->reg);
}
static void ksz9477_r_mib_cnt(struct ksz_device *dev, int port, u16 addr,
u64 *cnt)
{
struct ksz_port *p = &dev->ports[port];
struct ksz_read_ctx ctx = {
.dev = dev,
.p = &dev->ports[port],
.reg = REG_PORT_MIB_CTRL_STAT__4
};
u32 data;
int ret;
/* retain the flush/freeze bit */
data = p->freeze ? MIB_COUNTER_FLUSH_FREEZE : 0;
data |= MIB_COUNTER_READ;
data |= (addr << MIB_COUNTER_INDEX_S);
ksz_pwrite32(dev, port, REG_PORT_MIB_CTRL_STAT__4, data);
ret = readx_poll_timeout(ksz_pread32_poll, &ctx, data, !(data &
MIB_COUNTER_READ), 10, 1000);
Completely not compile tested, but you get the idea.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: Toke Høiland-Jørgensen @ 2019-02-21 23:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Miller, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <20190221134923.53c40b11@cakuba.netronome.com>
Jakub Kicinski <jakub.kicinski@netronome.com> writes:
> On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote:
>> A common pattern when using xdp_redirect_map() is to create a device map
>> where the lookup key is simply ifindex. Because device maps are arrays,
>> this leaves holes in the map, and the map has to be sized to fit the
>> largest ifindex, regardless of how many devices actually are actually
>> needed in the map.
>>
>> This patch adds a second type of device map where the key is interpreted as
>> an ifindex and looked up using a hashmap, instead of being used as an array
>> index. This leads to maps being densely packed, so they can be smaller.
>>
>> The default maps used by xdp_redirect() are changed to use the new map
>> type, which means that xdp_redirect() is no longer limited to ifindex < 64,
>> but instead to 64 total simultaneous interfaces per network namespace. This
>> also provides an easy way to compare the performance of devmap and
>> devmap_idx:
>>
>> xdp_redirect_map (devmap): 8394560 pkt/s
>> xdp_redirect (devmap_idx): 8179480 pkt/s
>>
>> Difference: 215080 pkt/s or 3.1 nanoseconds per packet.
>
> Could you share what the ifindex mix was here, to arrive at these
> numbers? How does it compare to using an array but not keying with
> ifindex?
Just the standard set on my test machine; ifindex 1 through 9, except 8
in this case. So certainly no more than 1 ifindex in each hash bucket
for those numbers.
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
>> +static int dev_map_idx_update_elem(struct bpf_map *map, void *key, void *value,
>> + u64 map_flags)
>> +{
>> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
>> + struct bpf_dtab_netdev *dev, *old_dev;
>> + u32 idx = *(u32 *)key;
>> + u32 val = *(u32 *)value;
>> + u32 bit;
>> +
>> + if (unlikely(map_flags > BPF_EXIST))
>> + return -EINVAL;
>> + if (unlikely(map_flags == BPF_NOEXIST))
>> + return -EEXIST;
>> +
>> + old_dev = __dev_map_idx_lookup_elem(map, idx);
>> + if (!val) {
>> + if (!old_dev)
>> + return 0;
>
> IMHO this is a fairly strange mix of array and hashmap semantics. I
> think you should stick to hashmap behaviour AFA flags and
> update/delete goes.
Yeah, the double book-keeping is a bit strange, but it allows the actual
forwarding and flush code to be reused between both types of maps. I
think this is worth the slight semantic confusion :)
-Toke
^ permalink raw reply
* Re: [PATCH RFC 3/5] sched/cpufreq: Fix incorrect RCU API usage
From: Rafael J. Wysocki @ 2019-02-21 23:05 UTC (permalink / raw)
To: Joel Fernandes (Google)
Cc: linux-kernel, Alexei Starovoitov, Christian Brauner,
Daniel Borkmann, David Ahern, David S. Miller, Ido Schimmel,
Ingo Molnar, moderated list:INTEL ETHERNET DRIVERS,
Jakub Kicinski, Jeff Kirsher, Jesper Dangaard Brouer,
John Fastabend, Josh Triplett, keescook, Lai Jiangshan,
Martin KaFai Lau, Mathieu Desnoyers, netdev, Paul E. McKenney,
Peter Zijlstra, rcu, Song Liu, Steven Rostedt, xdp-newbies,
Yonghong Song
In-Reply-To: <20190221054942.132388-4-joel@joelfernandes.org>
On Thursday, February 21, 2019 6:49:40 AM CET Joel Fernandes (Google) wrote:
> Recently I added an RCU annotation check to rcu_assign_pointer(). All
> pointers assigned to RCU protected data are to be annotated with __rcu
> inorder to be able to use rcu_assign_pointer() similar to checks in
> other RCU APIs.
>
> This resulted in a sparse error: kernel//sched/cpufreq.c:41:9: sparse:
> error: incompatible types in comparison expression (different address
> spaces)
>
> Fix this by using the correct APIs for RCU accesses. This will
> potentially avoid any future bugs in the code. If it is felt that RCU
> protection is not needed here, then the rcu_assign_pointer call can be
> dropped and replaced with, say, WRITE_ONCE or smp_store_release. Or, may
> be we add a new API to do it. But calls rcu_assign_pointer seems an
> abuse of the RCU API unless RCU is being used.
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> kernel/sched/cpufreq.c | 8 ++++++--
> kernel/sched/sched.h | 2 +-
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c
> index 22bd8980f32f..c9aeb3bf5dc2 100644
> --- a/kernel/sched/cpufreq.c
> +++ b/kernel/sched/cpufreq.c
> @@ -7,7 +7,7 @@
> */
> #include "sched.h"
>
> -DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
> +DEFINE_PER_CPU(struct update_util_data __rcu *, cpufreq_update_util_data);
>
> /**
> * cpufreq_add_update_util_hook - Populate the CPU's update_util_data pointer.
> @@ -34,8 +34,12 @@ void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
> if (WARN_ON(!data || !func))
> return;
>
> - if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
> + rcu_read_lock();
> + if (WARN_ON(rcu_dereference(per_cpu(cpufreq_update_util_data, cpu)))) {
> + rcu_read_unlock();
> return;
> + }
> + rcu_read_unlock();
As Steve said, this is not a read-side critical section, so the rcu_read_lock()
and rcu_read_unlock() don't help.
But rcu_access_pointer() should work here AFAICS.
Cheers,
Rafael
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/4] Sync up rdma_netlink.h
From: Jason Gunthorpe @ 2019-02-21 23:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Steve Wise, dsahern, leon, netdev, linux-rdma
In-Reply-To: <20190221105631.7dfa5217@shemminger-XPS-13-9360>
On Thu, Feb 21, 2019 at 10:56:31AM -0800, Stephen Hemminger wrote:
> On Thu, 21 Feb 2019 08:19:07 -0800
> Steve Wise <swise@opengridcomputing.com> wrote:
>
> > Pull in the latest rdma_netlink.h to get the RDMA_NLDEV_CMD_NEWLINK /
> > RDMA_NLDEV_CMD_DELLINK API.
> >
> > Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> > rdma/include/uapi/rdma/rdma_netlink.h | 74 +++++++++++++++++++++++++++--------
> > 1 file changed, 58 insertions(+), 16 deletions(-)
> >
> > diff --git a/rdma/include/uapi/rdma/rdma_netlink.h b/rdma/include/uapi/rdma/rdma_netlink.h
> > index 04c80cebef49..23a90ad52485 100644
> > +++ b/rdma/include/uapi/rdma/rdma_netlink.h
> > @@ -5,8 +5,7 @@
> > #include <linux/types.h>
> >
> > enum {
> > - RDMA_NL_RDMA_CM = 1,
> > - RDMA_NL_IWCM,
> > + RDMA_NL_IWCM = 2,
> > RDMA_NL_RSVD,
> > RDMA_NL_LS, /* RDMA Local Services */
> > RDMA_NL_NLDEV, /* RDMA device interface */
>
> You can't just drop elements from user ABI headers.
> That is a break of kernel ABI guarantee.
The ABI didn't change..
We don't promise unlimited source code compatibility in the uapi
headers.
If the kernel doesn't support something better to remove all traces of
it so userspace users are aware of the change when their compile
breaks.
Jason
^ permalink raw reply
* [PATCH 1/2] nl80211: Allow change CW to Ad-Hock network
From: Andrea Greco @ 2019-02-21 23:11 UTC (permalink / raw)
To: johannes.berg
Cc: Andrea Greco, Johannes Berg, David S. Miller, linux-wireless,
netdev, linux-kernel
From: Andrea Greco <a.greco@4sigma.it>
Add net-link support for change CW in Ad-Hock network
Signed-off-by: Andrea Greco <a.greco@4sigma.it>
---
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d91a408db113..4fcc63fa4380 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2731,7 +2731,8 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
if (netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
- netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO)
+ netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_P2P_GO &&
+ netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_ADHOC)
return -EINVAL;
if (!netif_running(netdev))
--
2.17.2
^ permalink raw reply related
* [PATCH 2/2] ath9K: debugfs: Fix SPUR-DOWN field
From: Andrea Greco @ 2019-02-21 23:12 UTC (permalink / raw)
To: johannes.berg
Cc: Andrea Greco, QCA ath9k Development, Kalle Valo, David S. Miller,
linux-wireless, netdev, linux-kernel
From: Andrea Greco <a.greco@4sigma.it>
SPUR DOWN field return spurup inside of spurdown
Signed-off-by: Andrea Greco <a.greco@4sigma.it>
---
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 4399e9ad058f..d4a2cdf9212c 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -148,7 +148,7 @@ static ssize_t read_file_ani(struct file *file, char __user *user_buf,
{ "OFDM LEVEL", ah->ani.ofdmNoiseImmunityLevel },
{ "CCK LEVEL", ah->ani.cckNoiseImmunityLevel },
{ "SPUR UP", ah->stats.ast_ani_spurup },
- { "SPUR DOWN", ah->stats.ast_ani_spurup },
+ { "SPUR DOWN", ah->stats.ast_ani_spurdown },
{ "OFDM WS-DET ON", ah->stats.ast_ani_ofdmon },
{ "OFDM WS-DET OFF", ah->stats.ast_ani_ofdmoff },
{ "MRC-CCK ON", ah->stats.ast_ani_ccklow },
--
2.17.2
^ permalink raw reply related
* Re: [PATCH v1 iproute2-next 3/4] rdma: add 'link add/delete' commands
From: Jason Gunthorpe @ 2019-02-21 23:14 UTC (permalink / raw)
To: Steve Wise; +Cc: dsahern, leon, stephen, netdev, linux-rdma
In-Reply-To: <5dd9d9aeada48bc5db0eb0394ed4e3ce38ee41bc.1550773362.git.swise@opengridcomputing.com>
On Thu, Feb 21, 2019 at 08:19:12AM -0800, Steve Wise wrote:
> Add new 'link' subcommand 'add' and 'delete' to allow binding a soft-rdma
> device to a netdev interface.
>
> EG:
>
> rdma link add rxe_eth0 type rxe netdev eth0
> rdma link delete rxe_eth0
This is great that we finally got here!
Jason
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] net: stmmac: Performance improvements in Multi-Queue
From: David Miller @ 2019-02-21 23:42 UTC (permalink / raw)
To: jose.abreu
Cc: netdev, linux-kernel, f.fainelli, joao.pinto, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <cover.1550569066.git.joabreu@synopsys.com>
From: Jose Abreu <jose.abreu@synopsys.com>
Date: Tue, 19 Feb 2019 10:38:46 +0100
> Tested in XGMAC2 and GMAC5.
Series applied, thanks Jose.
^ permalink raw reply
* Re: [PATCH net-next 00/10] mlxsw: Support for shared buffers in Spectrum-2
From: David Miller @ 2019-02-21 23:58 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20190220193141.16498-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Wed, 20 Feb 2019 19:32:10 +0000
> Petr says:
>
> Spectrum-2 will be configured with a different set of pools than
> Spectrum-1, their sizes will be larger, and the individual quotas will
> be different as well. It is therefore necessary to make the shared
> buffer module aware of this dependence on chip type, and adjust the
> individual tables.
>
> In patch #1, introduce a structure for keeping per-chip immutable and
> default values.
>
> In patch #2, structures for keeping current values of SBPM and SBPR
> (pool configuration and port-pool quota) are allocated dynamically to
> support varying pool counts.
>
> In patches #3 to #7, uses of individual shared buffer configuration
> tables are migrated from global definitions to fields in struct
> mlxsw_sp_sb_vals, which was introduced above.
>
> Up until this point, the actual configuration is still the one suitable
> for Spectrum-1. In patch #8 Spectrum-2 configuration is added.
>
> In patch #9, port headroom configuration is changed to take into account
> current recommended value for a 100-Gbps port, and the split factor.
>
> In patch #10, requests for overlarge headroom are rejected. This avoids
> potential chip freeze should such overlarge requests be made.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next 3/3] tipc: smooth change between replicast and broadcast
From: David Miller @ 2019-02-22 0:00 UTC (permalink / raw)
To: hoang.h.le; +Cc: jon.maloy, maloy, ying.xue, netdev, tipc-discussion
In-Reply-To: <20190219113054.13517-3-hoang.h.le@dektech.com.au>
From: Hoang Le <hoang.h.le@dektech.com.au>
Date: Tue, 19 Feb 2019 18:30:54 +0700
> +static int tipc_mcast_send_sync(struct net *net, struct sk_buff *skb,
> + struct tipc_mc_method *method,
> + struct tipc_nlist *dests,
> + u16 *cong_link_cnt)
> +{
> + struct sk_buff_head tmpq;
> + struct sk_buff *_skb;
> + struct tipc_msg *hdr, *_hdr;
Reverse christmas tree please.
> @@ -300,6 +372,9 @@ int tipc_mcast_xmit(struct net *net, struct sk_buff_head *pkts,
> u16 *cong_link_cnt)
> {
> struct sk_buff_head inputq, localq;
> + struct sk_buff *skb;
> + struct tipc_msg *hdr;
> + bool rcast = method->rcast;
> int rc = 0;
Likewise.
Thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] report erspan version field just for erspan tunnels
From: David Miller @ 2019-02-22 0:02 UTC (permalink / raw)
To: lorenzo.bianconi; +Cc: netdev, u9012063
In-Reply-To: <cover.1550594081.git.lorenzo.bianconi@redhat.com>
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date: Tue, 19 Feb 2019 17:42:04 +0100
> Do not report erspan_version to userpsace for non erspan tunnels.
> Report IFLA_GRE_ERSPAN_INDEX only for erspan version 1 in
> ip6gre_fill_info
Series applied, thanks.
^ permalink raw reply
* Re: pull request (net): ipsec 2019-02-21
From: David Miller @ 2019-02-22 0:09 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20190221082204.10134-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 21 Feb 2019 09:22:00 +0100
> 1) Don't do TX bytes accounting for the esp trailer when sending
> from a request socket as this will result in an out of bounds
> memory write. From Martin Willi.
>
> 2) Destroy xfrm_state synchronously on net exit path to
> avoid nested gc flush callbacks that may trigger a
> warning in xfrm6_tunnel_net_exit(). From Cong Wang.
>
> 3) Do an unconditionally clone in pfkey_broadcast_one()
> to avoid a race when freeing the skb.
> From Sean Tranchetti.
>
> 4) Fix inbound traffic via XFRM interfaces across network
> namespaces. We did the lookup for interfaces and policies
> in the wrong namespace. From Tobias Brunner.
>
> Please pull or let me know if there are problems.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2] iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Nick Desaulniers @ 2019-02-22 0:13 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, linux-wireless, netdev, LKML,
Arnd Bergmann
In-Reply-To: <20190221080617.2795-1-natechancellor@gmail.com>
On Thu, Feb 21, 2019 at 12:08 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Clang warns:
>
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: warning:
> comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long
> long *') and 'uint64_t *' (aka 'unsigned long long *'))
> [-Wcompare-distinct-pointer-types]
> do_div(rtt_avg, 6666);
> ^~~~~~~~~~~~~~~~~~~~~
> include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
> 1 warning generated.
>
> do_div expects an unsigned dividend. Use div_s64, which expects a signed
> dividend.
>
> Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
> Link: https://github.com/ClangBuiltLinux/linux/issues/372
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v1 -> v2:
>
> * Fix logic (as the return value of div{,64}_s64 must be used), thanks
> to Arnd for the review.
oh boy, sorry I missed that in the initial code review, thanks Arnd
for the sharp eye!
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Side tangent: we see this kind of difference in APIs a lot (modifying
the parameter vs returning a new value or making a copy then modifying
that) in C++ when a call site isn't passing the explicit address of
some variable or an identifier that's clearly a pointer. Ex.
int foo;
bar(foo);
Doesn't tell you whether bar mutates foo or not without looking at the
definition of bar, as it could be:
void bar(int x);
or
void bar(int& x);
I miss the convention in Ruby of using `!` suffixes on methods to
differentiate between such cases. ex:
"hello".capitalize
vs
"hello".capitalize!
both return the same value, but the one with the ! mutates the
existing object, while the one without creates a new object. And
that's a very standard convention throughout the standard library.
Whether or not people follow that convention is always another story.
One thing I'm curious about, is "why does do_div exist?" When should I
use do_div vs div_u64 (not div_s64 as is used in this patch)?
>
> drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> index e9822a3ec373..94132cfd1f56 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> @@ -460,9 +460,7 @@ static int iwl_mvm_ftm_range_resp_valid(struct iwl_mvm *mvm, u8 request_id,
> static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm, u8 index,
> struct cfg80211_pmsr_result *res)
> {
> - s64 rtt_avg = res->ftm.rtt_avg * 100;
> -
> - do_div(rtt_avg, 6666);
> + s64 rtt_avg = div_s64(res->ftm.rtt_avg * 100, 6666);
>
> IWL_DEBUG_INFO(mvm, "entry %d\n", index);
> IWL_DEBUG_INFO(mvm, "\tstatus: %d\n", res->status);
> --
> 2.21.0.rc1
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH bpf-next v2] bpf, seccomp: fix false positive preemption splat for cbpf->ebpf progs
From: Andy Lutomirski @ 2019-02-22 0:22 UTC (permalink / raw)
To: Kees Cook
Cc: Alexei Starovoitov, Jann Horn, Daniel Borkmann,
Alexei Starovoitov, Network Development
In-Reply-To: <CAGXu5jKb4F7pa5=0bHH9T494Cnk_y=4TxrX2BecrvuvFZPAhaQ@mail.gmail.com>
On Thu, Feb 21, 2019 at 2:14 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Thu, Feb 21, 2019 at 12:36 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > I also would like to touch on your comment:
> > "A lot of changes will be needed for seccomp ebpf"
> > There were two attempts to add it in the past and the patches were
> > small and straightforward.
>
> Yeah, agreed: doing it is technically easy. My concerns have mainly
> revolved around avoiding increased complexity and attack surface.
> There have been, for example, a lot of verifier bugs that were not
> reachable through seccomp's BPF usage, given it enforcing only using a
> subset of cBPF. i.e. seccomp filters couldn't be used as Spectre
> gadgets, etc.
>
> > If I recall correctly both times you nacked them because performance gains
> > and ease of use arguments were not convincing enough, right?
>
> Right. There wasn't, in my opinion enough of a performance benefit vs
> just having efficient BPF to start with.
>
> > Are you still not convinced ?
>
> For now, yeah. I'm sure there will be some future time when a use-case
> appears where gaining some special eBPF hook/feature will outweigh the
> increased attack surface. I haven't seen it yet, but I'm not crazy
> enough to think it'll never happen. (In fact, recently I even had
> Tycho see if he could implement the recent seccomp user notification
> stuff via eBPF.)
>
I consider the potential for much improved performance to be a
maybe-good-enough argument. The down side is that there are programs
that load cBPF seccomp filters from inside a sandbox, and being able
to load eBPF from inside a sandbox is potentially undesirable.
^ permalink raw reply
* Re: [PATCH net-next] ip_tunnel: Add dst_cache management lwtunnel_state of ip tunnel
From: kbuild test robot @ 2019-02-22 0:23 UTC (permalink / raw)
To: wenxu; +Cc: kbuild-all, netdev, davem
In-Reply-To: <1550763703-15783-1-git-send-email-wenxu@ucloud.cn>
[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]
Hi wenxu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/wenxu-ucloud-cn/ip_tunnel-Add-dst_cache-management-lwtunnel_state-of-ip-tunnel/20190222-074749
config: i386-randconfig-x007-201907 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-20) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
net//ipv4/ip_tunnel_core.c: In function 'ip_tun_destroy_state':
>> net//ipv4/ip_tunnel_core.c:292:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
net//ipv4/ip_tunnel_core.c: At top level:
>> net//ipv4/ip_tunnel_core.c:329:19: error: initialization of 'void (*)(struct lwtunnel_state *)' from incompatible pointer type 'int (*)(struct lwtunnel_state *)' [-Werror=incompatible-pointer-types]
.destroy_state = ip_tun_destroy_state,
^~~~~~~~~~~~~~~~~~~~
net//ipv4/ip_tunnel_core.c:329:19: note: (near initialization for 'ip_tun_lwt_ops.destroy_state')
cc1: some warnings being treated as errors
vim +329 net//ipv4/ip_tunnel_core.c
286
287 static int ip_tun_destroy_state(struct lwtunnel_state *lwtstate)
288 {
289 struct ip_tunnel_info *tun_info = lwt_tun_info(lwtstate);
290
291 dst_cache_destroy(&tun_info->dst_cache);
> 292 }
293
294 static int ip_tun_fill_encap_info(struct sk_buff *skb,
295 struct lwtunnel_state *lwtstate)
296 {
297 struct ip_tunnel_info *tun_info = lwt_tun_info(lwtstate);
298
299 if (nla_put_be64(skb, LWTUNNEL_IP_ID, tun_info->key.tun_id,
300 LWTUNNEL_IP_PAD) ||
301 nla_put_in_addr(skb, LWTUNNEL_IP_DST, tun_info->key.u.ipv4.dst) ||
302 nla_put_in_addr(skb, LWTUNNEL_IP_SRC, tun_info->key.u.ipv4.src) ||
303 nla_put_u8(skb, LWTUNNEL_IP_TOS, tun_info->key.tos) ||
304 nla_put_u8(skb, LWTUNNEL_IP_TTL, tun_info->key.ttl) ||
305 nla_put_be16(skb, LWTUNNEL_IP_FLAGS, tun_info->key.tun_flags))
306 return -ENOMEM;
307
308 return 0;
309 }
310
311 static int ip_tun_encap_nlsize(struct lwtunnel_state *lwtstate)
312 {
313 return nla_total_size_64bit(8) /* LWTUNNEL_IP_ID */
314 + nla_total_size(4) /* LWTUNNEL_IP_DST */
315 + nla_total_size(4) /* LWTUNNEL_IP_SRC */
316 + nla_total_size(1) /* LWTUNNEL_IP_TOS */
317 + nla_total_size(1) /* LWTUNNEL_IP_TTL */
318 + nla_total_size(2); /* LWTUNNEL_IP_FLAGS */
319 }
320
321 static int ip_tun_cmp_encap(struct lwtunnel_state *a, struct lwtunnel_state *b)
322 {
323 return memcmp(lwt_tun_info(a), lwt_tun_info(b),
324 sizeof(struct ip_tunnel_info));
325 }
326
327 static const struct lwtunnel_encap_ops ip_tun_lwt_ops = {
328 .build_state = ip_tun_build_state,
> 329 .destroy_state = ip_tun_destroy_state,
330 .fill_encap = ip_tun_fill_encap_info,
331 .get_encap_size = ip_tun_encap_nlsize,
332 .cmp_encap = ip_tun_cmp_encap,
333 .owner = THIS_MODULE,
334 };
335
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30912 bytes --]
^ permalink raw reply
* Re: [PATCH] phonet: fix building with clang
From: David Miller @ 2019-02-22 0:24 UTC (permalink / raw)
To: arnd; +Cc: courmisch, natechancellor, remi, netdev, linux-kernel
In-Reply-To: <20190219215359.391543-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 19 Feb 2019 22:53:50 +0100
> clang warns about overflowing the data[] member in the struct pnpipehdr:
>
> net/phonet/pep.c:295:8: warning: array index 4 is past the end of the array (which contains 1 element) [-Warray-bounds]
> if (hdr->data[4] == PEP_IND_READY)
> ^ ~
> include/net/phonet/pep.h:66:3: note: array 'data' declared here
> u8 data[1];
>
> Using a flexible array member at the end of the struct avoids the
> warning, but since we cannot have a flexible array member inside
> of the union, each index now has to be moved back by one, which
> makes it a little uglier.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] ip_tunnel: Add dst_cache management lwtunnel_state of ip tunnel
From: kbuild test robot @ 2019-02-22 0:29 UTC (permalink / raw)
To: wenxu; +Cc: kbuild-all, netdev, davem
In-Reply-To: <1550763703-15783-1-git-send-email-wenxu@ucloud.cn>
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]
Hi wenxu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/wenxu-ucloud-cn/ip_tunnel-Add-dst_cache-management-lwtunnel_state-of-ip-tunnel/20190222-074749
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=6.4.0 make.cross ARCH=nds32
All errors (new ones prefixed by >>):
net//ipv4/ip_tunnel_core.c: In function 'ip_tun_destroy_state':
net//ipv4/ip_tunnel_core.c:292:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
net//ipv4/ip_tunnel_core.c: At top level:
>> net//ipv4/ip_tunnel_core.c:329:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.destroy_state = ip_tun_destroy_state,
^~~~~~~~~~~~~~~~~~~~
net//ipv4/ip_tunnel_core.c:329:19: note: (near initialization for 'ip_tun_lwt_ops.destroy_state')
cc1: some warnings being treated as errors
vim +329 net//ipv4/ip_tunnel_core.c
286
287 static int ip_tun_destroy_state(struct lwtunnel_state *lwtstate)
288 {
289 struct ip_tunnel_info *tun_info = lwt_tun_info(lwtstate);
290
291 dst_cache_destroy(&tun_info->dst_cache);
> 292 }
293
294 static int ip_tun_fill_encap_info(struct sk_buff *skb,
295 struct lwtunnel_state *lwtstate)
296 {
297 struct ip_tunnel_info *tun_info = lwt_tun_info(lwtstate);
298
299 if (nla_put_be64(skb, LWTUNNEL_IP_ID, tun_info->key.tun_id,
300 LWTUNNEL_IP_PAD) ||
301 nla_put_in_addr(skb, LWTUNNEL_IP_DST, tun_info->key.u.ipv4.dst) ||
302 nla_put_in_addr(skb, LWTUNNEL_IP_SRC, tun_info->key.u.ipv4.src) ||
303 nla_put_u8(skb, LWTUNNEL_IP_TOS, tun_info->key.tos) ||
304 nla_put_u8(skb, LWTUNNEL_IP_TTL, tun_info->key.ttl) ||
305 nla_put_be16(skb, LWTUNNEL_IP_FLAGS, tun_info->key.tun_flags))
306 return -ENOMEM;
307
308 return 0;
309 }
310
311 static int ip_tun_encap_nlsize(struct lwtunnel_state *lwtstate)
312 {
313 return nla_total_size_64bit(8) /* LWTUNNEL_IP_ID */
314 + nla_total_size(4) /* LWTUNNEL_IP_DST */
315 + nla_total_size(4) /* LWTUNNEL_IP_SRC */
316 + nla_total_size(1) /* LWTUNNEL_IP_TOS */
317 + nla_total_size(1) /* LWTUNNEL_IP_TTL */
318 + nla_total_size(2); /* LWTUNNEL_IP_FLAGS */
319 }
320
321 static int ip_tun_cmp_encap(struct lwtunnel_state *a, struct lwtunnel_state *b)
322 {
323 return memcmp(lwt_tun_info(a), lwt_tun_info(b),
324 sizeof(struct ip_tunnel_info));
325 }
326
327 static const struct lwtunnel_encap_ops ip_tun_lwt_ops = {
328 .build_state = ip_tun_build_state,
> 329 .destroy_state = ip_tun_destroy_state,
330 .fill_encap = ip_tun_fill_encap_info,
331 .get_encap_size = ip_tun_encap_nlsize,
332 .cmp_encap = ip_tun_cmp_encap,
333 .owner = THIS_MODULE,
334 };
335
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49937 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: Jakub Kicinski @ 2019-02-22 0:32 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: David Miller, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <874l8wiw3k.fsf@toke.dk>
On Fri, 22 Feb 2019 00:02:23 +0100, Toke Høiland-Jørgensen wrote:
> Jakub Kicinski <jakub.kicinski@netronome.com> writes:
>
> > On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote:
> >> A common pattern when using xdp_redirect_map() is to create a device map
> >> where the lookup key is simply ifindex. Because device maps are arrays,
> >> this leaves holes in the map, and the map has to be sized to fit the
> >> largest ifindex, regardless of how many devices actually are actually
> >> needed in the map.
> >>
> >> This patch adds a second type of device map where the key is interpreted as
> >> an ifindex and looked up using a hashmap, instead of being used as an array
> >> index. This leads to maps being densely packed, so they can be smaller.
> >>
> >> The default maps used by xdp_redirect() are changed to use the new map
> >> type, which means that xdp_redirect() is no longer limited to ifindex < 64,
> >> but instead to 64 total simultaneous interfaces per network namespace. This
> >> also provides an easy way to compare the performance of devmap and
> >> devmap_idx:
> >>
> >> xdp_redirect_map (devmap): 8394560 pkt/s
> >> xdp_redirect (devmap_idx): 8179480 pkt/s
> >>
> >> Difference: 215080 pkt/s or 3.1 nanoseconds per packet.
> >
> > Could you share what the ifindex mix was here, to arrive at these
> > numbers? How does it compare to using an array but not keying with
> > ifindex?
>
> Just the standard set on my test machine; ifindex 1 through 9, except 8
> in this case. So certainly no more than 1 ifindex in each hash bucket
> for those numbers.
Oh, I clearly misread your numbers, it's still slower than array, you
just don't need the size limit.
> >> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> >
> >> +static int dev_map_idx_update_elem(struct bpf_map *map, void *key, void *value,
> >> + u64 map_flags)
> >> +{
> >> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
> >> + struct bpf_dtab_netdev *dev, *old_dev;
> >> + u32 idx = *(u32 *)key;
> >> + u32 val = *(u32 *)value;
> >> + u32 bit;
> >> +
> >> + if (unlikely(map_flags > BPF_EXIST))
> >> + return -EINVAL;
> >> + if (unlikely(map_flags == BPF_NOEXIST))
> >> + return -EEXIST;
> >> +
> >> + old_dev = __dev_map_idx_lookup_elem(map, idx);
> >> + if (!val) {
> >> + if (!old_dev)
> >> + return 0;
> >
> > IMHO this is a fairly strange mix of array and hashmap semantics. I
> > think you should stick to hashmap behaviour AFA flags and
> > update/delete goes.
>
> Yeah, the double book-keeping is a bit strange, but it allows the actual
> forwarding and flush code to be reused between both types of maps. I
> think this is worth the slight semantic confusion :)
I'm not sure I was clear, let me try again :) Your get_next_key only
reports existing indexes if I read the code right, so that's not an
array - in an array indexes always exist. What follows inserting 0
should not be equivalent to delete and BPF_NOEXIST should be handled
appropriately.
Different maps behave differently, I think it's worth trying to limit
the divergence in how things behave to the basic array and a hashmap
models when possible.
^ permalink raw reply
* Re: [Patch net-next 00/12] code optimizations & bugfixes for HNS3 driver
From: David Miller @ 2019-02-22 0:34 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1550629971-23999-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Wed, 20 Feb 2019 10:32:39 +0800
> This patchset includes bugfixes and code optimizations for
> the HNS3 ethernet controller driver.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH iproute2] ss: Render buffer to output every time a number of chunks are allocated
From: Stephen Hemminger @ 2019-02-22 0:35 UTC (permalink / raw)
To: Stefano Brivio
Cc: Eric Dumazet, Phil Sutter, David Ahern, Sabrina Dubroca, netdev
In-Reply-To: <03dd56e5161a3c1270a21c4ba3f6e695793dbb74.1550105375.git.sbrivio@redhat.com>
On Thu, 14 Feb 2019 01:58:32 +0100
Stefano Brivio <sbrivio@redhat.com> wrote:
> Eric reported that, with 10 million sockets, ss -emoi (about 1000 bytes
> output per socket) can easily lead to OOM (buffer would grow to 10GB of
> memory).
>
> Limit the maximum size of the buffer to five chunks, 1M each. Render and
> flush buffers whenever we reach that.
>
> This might make the resulting blocks slightly unaligned between them, with
> occasional loss of readability on lines occurring every 5k to 50k sockets
> approximately. Something like (from ss -tu):
Applied.
Interesting that with a small system the number of syscalls did not change
^ 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