* [RESEND PATCH 5/6] staging: fsl-dpaa2/ethsw: Add README
From: Razvan Stefanescu @ 2017-09-19 12:45 UTC (permalink / raw)
To: gregkh
Cc: devel, arnd, netdev, alexandru.marginean, linux-kernel, agraf,
stuyoder, bogdan.purcareata, laurentiu.tudor
In-Reply-To: <1505825158-8192-1-git-send-email-razvan.stefanescu@nxp.com>
Add a README file describing the driver architecture, components and
interfaces.
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/README | 106 +++++++++++++++++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/README
diff --git a/drivers/staging/fsl-dpaa2/ethsw/README b/drivers/staging/fsl-dpaa2/ethsw/README
new file mode 100644
index 0000000..f6fc07f
--- /dev/null
+++ b/drivers/staging/fsl-dpaa2/ethsw/README
@@ -0,0 +1,106 @@
+DPAA2 Ethernet Switch driver
+============================
+
+This file provides documentation for the DPAA2 Ethernet Switch driver
+
+
+Contents
+========
+ Supported Platforms
+ Architecture Overview
+ Creating an Ethernet Switch
+ Features
+
+
+ Supported Platforms
+===================
+This driver provides networking support for Freescale LS2085A, LS2088A
+DPAA2 SoCs.
+
+
+Architecture Overview
+=====================
+The Ethernet Switch in the DPAA2 architecture consists of several hardware
+resources that provide the functionality. These are allocated and
+configured via the Management Complex (MC) portals. MC abstracts most of
+these resources as DPAA2 objects and exposes ABIs through which they can
+be configured and controlled.
+
+For a more detailed description of the DPAA2 architecture and its object
+abstractions see:
+ drivers/staging/fsl-mc/README.txt
+
+The Ethernet Switch is built on top of a Datapath Switch (DPSW) object.
+
+Configuration interface:
+
+ ---------------------
+ | DPAA2 Switch driver |
+ ---------------------
+ .
+ .
+ ----------
+ | DPSW API |
+ ----------
+ . software
+ ================= . ==============
+ . hardware
+ ---------------------
+ | MC hardware portals |
+ ---------------------
+ .
+ .
+ ------
+ | DPSW |
+ ------
+
+Driver uses the switch device driver model and exposes each switch port as
+a network interface, which can be included in a bridge. Traffic switched
+between ports is offloaded into the hardware. Exposed network interfaces
+are not used for I/O, they are used just for configuration. This
+limitation is going to be addressed in the future.
+
+The DPSW can have ports connected to DPNIs or to PHYs via DPMACs.
+
+
+ [ethA] [ethB] [ethC] [ethD] [ethE] [ethF]
+ : : : : : :
+ : : : : : :
+[eth drv] [eth drv] [ ethsw drv ]
+ : : : : : : kernel
+========================================================================
+ : : : : : : hardware
+ [DPNI] [DPNI] [============= DPSW =================]
+ | | | | | |
+ | ---------- | [DPMAC] [DPMAC]
+ ------------------------------- | |
+ | |
+ [PHY] [PHY]
+
+For a more detailed description of the Ethernet switch device driver model
+see:
+ Documentation/networking/switchdev.txt
+
+Creating an Ethernet Switch
+===========================
+A device is created for the switch objects probed on the MC bus. Each DPSW
+has a number of properties which determine the configuration options and
+associated hardware resources.
+
+A DPSW object (and the other DPAA2 objects needed for a DPAA2 switch) can
+be added to a container on the MC bus in one of two ways: statically,
+through a Datapath Layout Binary file (DPL) that is parsed by MC at boot
+time; or created dynamically at runtime, via the DPAA2 objects APIs.
+
+Features
+========
+Driver configures DPSW to perform hardware switching offload of
+unicast/multicast/broadcast (VLAN tagged or untagged) traffic between its
+ports.
+
+It allows configuration of hardware learning, flooding, multicast groups,
+port VLAN configuration and STP state.
+
+Static entries can be added/removed from the FDB.
+
+Hardware statistics for each port are provided through ethtool -S option.
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 6/6] staging: fsl-dpaa2/ethsw: Add TODO
From: Razvan Stefanescu @ 2017-09-19 12:45 UTC (permalink / raw)
To: gregkh
Cc: devel, arnd, netdev, alexandru.marginean, linux-kernel, agraf,
stuyoder, bogdan.purcareata, laurentiu.tudor
In-Reply-To: <1505825158-8192-1-git-send-email-razvan.stefanescu@nxp.com>
Add a TODO file describing what needs to be added/changed before the driver
can be moved out of staging.
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@nxp.com>
---
drivers/staging/fsl-dpaa2/ethsw/TODO | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 drivers/staging/fsl-dpaa2/ethsw/TODO
diff --git a/drivers/staging/fsl-dpaa2/ethsw/TODO b/drivers/staging/fsl-dpaa2/ethsw/TODO
new file mode 100644
index 0000000..d3f12c3
--- /dev/null
+++ b/drivers/staging/fsl-dpaa2/ethsw/TODO
@@ -0,0 +1,14 @@
+* Add I/O capabilities on switch port netdevices. This will allow control
+traffic to reach the CPU.
+* Add ACL to redirect control traffic to CPU.
+* Add support for displaying learned FDB entries
+* MC firmware uprev; the DPAA2 objects used by the Ethernet Switch driver
+need to be kept in sync with binary interface changes in MC
+* refine README file
+* cleanup
+
+NOTE: At least first three of the above are required before getting the
+DPAA2 Ethernet Switch driver out of staging. Another requirement is that
+the fsl-mc bus driver is moved to drivers/bus and dpio driver is moved to
+drivers/soc (this is required for I/O).
+
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] net: avoid a full fib lookup when rp_filter is disabled.
From: Paolo Abeni @ 2017-09-19 12:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David S. Miller, Hannes Frederic Sowa
In-Reply-To: <1505822433.29839.44.camel@edumazet-glaptop3.roam.corp.google.com>
Hi,
On Tue, 2017-09-19 at 05:00 -0700, Eric Dumazet wrote:
> On Tue, 2017-09-19 at 12:46 +0200, Paolo Abeni wrote:
> ..
>
> > Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > ---
> > +/* called under RCU lock */
> > +struct in_ifaddr *inet_lookup_ifaddr_rcu(struct net *net, __be32 addr)
> > +{
> > + u32 hash = inet_addr_hash(net, addr);
> > + struct in_ifaddr *ifa;
> > +
> > + hlist_for_each_entry_rcu(ifa, &inet_addr_lst[hash], hash)
> > + if (ifa->ifa_local == addr &&
> > + net_eq(dev_net(ifa->ifa_dev->dev), net))
> > + return ifa;
> > +
> > + return NULL;
> > +}
> > +
Thank you for reviewing this!
> Any particular reason you do not use this helper to replace the lookup
> in __ip_dev_find() ?
uh, I just missed that opportunity. I'll send a v2, thanks!
Paolo
^ permalink raw reply
* RE: [PATCH net-next 05/12] net: dsa: b53: Use a macro to define I/O operations
From: David Laight @ 2017-09-19 12:53 UTC (permalink / raw)
To: 'Florian Fainelli', netdev@vger.kernel.org
Cc: davem@davemloft.net, andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com
In-Reply-To: <20170918214128.27896-6-f.fainelli@gmail.com>
From: Florian Fainelli
> Sent: 18 September 2017 22:41
> Instead of repeating the same pattern: acquire mutex, read/write, release
> mutex, define a macro: b53_build_op() which takes the type (read|write), I/O
> size, and value (scalar or pointer). This helps with fixing bugs that could
> exit (e.g: missing barrier, lock etc.).
....
> +#define b53_build_op(type, op_size, val_type) \
> +static inline int b53_##type##op_size(struct b53_device *dev, u8 page, \
> + u8 reg, val_type val) \
> +{ \
> + int ret; \
> + \
> + mutex_lock(&dev->reg_mutex); \
> + ret = dev->ops->type##op_size(dev, page, reg, val); \
> + mutex_unlock(&dev->reg_mutex); \
> + \
> + return ret; \
> }
Why separate the 'type' and 'op_size' arguments since they
are always pasted together?
David
^ permalink raw reply
* [PATCH] ipv6_skip_exthdr: use ipv6_authlen for AH hdrlen
From: Xiang Gao @ 2017-09-19 12:59 UTC (permalink / raw)
To: trivial, netdev, davem, kuznet, yoshfuji; +Cc: qasdfgtyuiop
In ipv6_skip_exthdr, the lengh of AH header is computed manually
as (hp->hdrlen+2)<<2. However, in include/linux/ipv6.h, a macro
named ipv6_authlen is already defined for exactly the same job. This
commit replaces the manual computation code with the macro.
---
net/ipv6/exthdrs_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 305e2ed730bf..115d60919f72 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -99,7 +99,7 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
break;
hdrlen = 8;
} else if (nexthdr == NEXTHDR_AUTH)
- hdrlen = (hp->hdrlen+2)<<2;
+ hdrlen = ipv6_authlen(hp);
else
hdrlen = ipv6_optlen(hp);
--
2.14.1
^ permalink raw reply related
* Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces for traffic shapers
From: Henrik Austad @ 2017-09-19 13:14 UTC (permalink / raw)
To: Richard Cochran
Cc: Vinicius Costa Gomes, netdev, jhs, xiyou.wangcong, jiri,
intel-wired-lan, andre.guedes, ivan.briano,
jesus.sanchez-palencia, boon.leong.ong
In-Reply-To: <20170919052244.77umdxuze53t6j22@localhost>
[-- Attachment #1: Type: text/plain, Size: 4710 bytes --]
Hi all,
On Tue, Sep 19, 2017 at 07:22:44AM +0200, Richard Cochran wrote:
> On Mon, Sep 18, 2017 at 04:06:28PM -0700, Vinicius Costa Gomes wrote:
> > That's the point, the application does not need to know that, and asking
> > that would be stupid.
>
> On the contrary, this information is essential to the application.
> Probably you have never seen an actual Ethernet field bus in
> operation? In any case, you are missing the point.
>
> > (And that's another nice point of how 802.1Qbv works, applications do
> > not need to be changed to use it, and I think we should work to achieve
> > this on the Linux side)
>
> Once you start to care about real time performance, then you need to
> consider the applications. This is industrial control, not streaming
> your tunes from your ipod.
Do not underestimate the need for media over TSN. I fully see your point of
real-time systems, but they are not the only valid use-cases for TSN.
> > That being said, that only works for kinds of traffic that maps well to
> > this configuration in advance model, which is the model that the IEEE
> > (see 802.1Qcc) and the AVNU Alliance[1] are pushing for.
>
> Again, you are missing the point of what they aiming for. I have
> looked at a number of production systems, and in each case the
> developers want total control over the transmission, in order to
> reduce latency to an absolute minimum. Typically the data to be sent
> are available only microseconds before the transmission deadline.
>
> Consider OpenAVB on github that people are already using. Take a look
> at simple_talker.c and explain how "applications do not need to be
> changed to use it."
I do not think simple-talker was everintended to be how users of AVB should
be implemented, but as a demonstration of what the protocol could do.
ALSA/V4L2 should supply some interface to this so that you can attach
media-applications to it without the application itself having to be "TSN
aware".
> > [1]
> > http://avnu.org/theory-of-operation-for-tsn-enabled-industrial-systems/
>
> Did you even read this?
>
> [page 24]
>
> As described in section 2, some industrial control systems require
> predictable, very low latency and cycle-to-cycle variation to meet
> hard real-time application requirements. In these systems,
> multiple distributed controllers commonly synchronize their
> sensor/actuator operations with other controllers by scheduling
> these operations in time, typically using a repeating control
> cycle.
> ...
> The gate control mechanism is itself a time-aware PTP application
> operating within a bridge or end station port.
>
> It is an application, not a "god box."
>
> > In short, I see a per-packet transmission time and a per-queue schedule
> > as solutions to different problems.
>
> Well, I can agree with that. For some non real-time applications,
> bandwidth shaping is enough, and your Qdisc idea is sufficient. For
> the really challenging TSN targets (industrial control, automotive),
> your idea of an opaque schedule file won't fly.
Would it make sense to adapt the proposed Qdisc here as well as the
back-o-the-napkin idea in the other thread to to a per-socket queue for
each priority and then sort those sockets based on SO_TXTIME?
TSN operates on a per-StreamID basis, and that should map fairly well to a
per-socket approach I think (let us just assume that an application that
sends TSN traffic will open up a separate socket for each stream.
This should allow a userspace application that is _very_ aware of its
timing constraints to send frames exactly when it needs to as you have
SO_TXTIME available. It would also let applications that basically want a
fine-grained rate control (audio and video comes to mind) to use the same
qdisc.
For those sockets that do not support SO_TXTIME, but still map to a
priority handled by sch_cbs (or whatever it'll end up being called) you can
set the transmit-time to be the time of the last skb in the queue + an
delta which will give you the correct rate (TSN operates on observation
intervals which you can specify via tc when you create the queues).
Then you can have, as you propose in your other series, a hrtimer that is
being called when the next SO_TXTIME enters, grab a skb and move it to the
hw-queue. This should also allow you to keep a sorted per-socket queue
should an application send frames in the wrong order, without having to
rearrange descriptors for the DMA machinery.
If this makes sense, I am more than happy to give it a stab and see how it
goes.
-Henrik
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* software interrupts close to 100 with 9000 tc filter entries
From: Marco Berizzi @ 2017-09-19 13:28 UTC (permalink / raw)
To: netdev
Hi Folks,
I'm running linux 4.12.10 x86_64 on a Slackware 14.2 64bit
as a simple 4 NIC router. Network throughput processed by
this machine is less than 200Mbit/s
The cpu model is Intel(R) Xeon(R) CPU 5160 @ 3.00GHz with
2GB ram.
I need to blacklist about 9000 single ip addresses.
This is the relevant script to blacklist these ip addresses:
tc qdisc add dev eth0 ingress
tc qdisc add dev eth1 ingress
while read -r line
do
tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src $line action drop
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src $line action drop
done < blacklisted_ip_addresses
After loading these ip addresses, the si (software interrupts)
number shown by top is always close to 100
If I delete the ingress qdisc on both the device, the si
fall down to less than 5
Running the same script with 'only' 700 ip addresses is
flawless.
Kindly I would like to ask if am I doing anything in
a wrong way or if the hardware is too old for this kind
of setup.
I have selected the tc filter setup instead of netfilter
one, because I was reading this from iproute2/doc/actions:
A side effect is that we can now get stateless firewalling to work with tc..
Essentially this is now an alternative to iptables.
I wont go into details of my dislike for iptables at times, but.
scalability is one of the main issues; however, if you need stateful
classification - use netfilter (for now).
Any response are welcome
TIA
Marco
^ permalink raw reply
* Re: [PATCH 2/3] selftests: actually run the various net selftests
From: Josef Bacik @ 2017-09-19 13:34 UTC (permalink / raw)
To: Willem de Bruijn
Cc: josef, Josef Bacik, David S. Miller, linux-kernel,
linux-kselftest, netdev, Shuah Khan, Shuah Khan
In-Reply-To: <09f17145-5f0a-ec61-3dfb-69216eac7133@kernel.org>
On Mon, Sep 18, 2017 at 04:14:41PM -0600, Shuah Khan wrote:
> On 09/18/2017 11:32 AM, josef@toxicpanda.com wrote:
> > From: Josef Bacik <jbacik@fb.com>
> >
> > These self tests are just self contained binaries, they are not run by
> > any of the scripts in the directory. This means they need to be marked
> > with TEST_GEN_PROGS to actually be run, not TEST_GEN_FILES.
> >
> > Signed-off-by: Josef Bacik <jbacik@fb.com>
> > ---
> > tools/testing/selftests/net/Makefile | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> > index 3df542c84610..45a4e77a47c4 100644
> > --- a/tools/testing/selftests/net/Makefile
> > +++ b/tools/testing/selftests/net/Makefile
> > @@ -6,8 +6,8 @@ CFLAGS += -I../../../../usr/include/
> > TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
> > TEST_GEN_FILES = socket
> > TEST_GEN_FILES += psock_fanout psock_tpacket
> > -TEST_GEN_FILES += reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
> > -TEST_GEN_FILES += reuseport_dualstack msg_zerocopy reuseaddr_conflict
> > +TEST_GEN_PROGS += reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
> > +TEST_GEN_PROGS += reuseport_dualstack msg_zerocopy reuseaddr_conflict
>
> Hmm. I see msg_zerocopy.sh for running msg_zerocopy. msg_zerocopy should
> still stay in TEST_GEN_FILES and msg_zerocopy.sh needs to be added to
> TEST_PROGS so it runs.
>
Actually the shell script requires arguments, it doesn't just run the test.
I'll fix this to just omit the test for now as it's not setup to run properly.
Willem, could you follow up with a patch so that the zero copy test is run
properly the way you envision it running? You need to make sure that
make -C tools/testing/selftests TARGETS=net run_tests
actually runs your zero copy test the way you expect it to, otherwise it's just
sitting there collecting dust. Thanks,
Josef
^ permalink raw reply
* [PATCH net v2] l2tp: fix race condition in l2tp_tunnel_delete
From: Sabrina Dubroca @ 2017-09-19 13:40 UTC (permalink / raw)
To: netdev; +Cc: Sabrina Dubroca, Guillaume Nault, Xin Long, Tom Parkin
If we try to delete the same tunnel twice, the first delete operation
does a lookup (l2tp_tunnel_get), finds the tunnel, calls
l2tp_tunnel_delete, which queues it for deletion by
l2tp_tunnel_del_work.
The second delete operation also finds the tunnel and calls
l2tp_tunnel_delete. If the workqueue has already fired and started
running l2tp_tunnel_del_work, then l2tp_tunnel_delete will queue the
same tunnel a second time, and try to free the socket again.
Add a dead flag to prevent firing the workqueue twice. Then we can
remove the check of queue_work's result that was meant to prevent that
race but doesn't.
Also check the flag in the tunnel lookup functions, to avoid returning a
tunnel that is already scheduled for destruction.
Reproducer:
ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 local 192.168.0.2 remote 192.168.0.1 encap udp udp_sport 5000 udp_dport 6000
ip l2tp add session name l2tp1 tunnel_id 3000 session_id 1000 peer_session_id 2000
ip link set l2tp1 up
ip l2tp del tunnel tunnel_id 3000
ip l2tp del tunnel tunnel_id 3000
Fixes: f8ccac0e4493 ("l2tp: put tunnel socket release on a workqueue")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
v2: as Tom Parkin explained, we can't remove the tunnel from the
per-net list from netlink. v2 uses only a dead flag, and adds
corresponding checks during lookups
net/l2tp/l2tp_core.c | 18 +++++++++---------
net/l2tp/l2tp_core.h | 5 ++++-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index ee485df73ccd..3891f0260f2b 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -203,7 +203,8 @@ struct l2tp_tunnel *l2tp_tunnel_get(const struct net *net, u32 tunnel_id)
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- if (tunnel->tunnel_id == tunnel_id) {
+ if (tunnel->tunnel_id == tunnel_id &&
+ !test_bit(0, &tunnel->dead)) {
l2tp_tunnel_inc_refcount(tunnel);
rcu_read_unlock_bh();
@@ -390,7 +391,8 @@ struct l2tp_tunnel *l2tp_tunnel_find(const struct net *net, u32 tunnel_id)
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- if (tunnel->tunnel_id == tunnel_id) {
+ if (tunnel->tunnel_id == tunnel_id &&
+ !test_bit(0, &tunnel->dead)) {
rcu_read_unlock_bh();
return tunnel;
}
@@ -409,7 +411,7 @@ struct l2tp_tunnel *l2tp_tunnel_find_nth(const struct net *net, int nth)
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- if (++count > nth) {
+ if (++count > nth && !test_bit(0, &tunnel->dead)) {
rcu_read_unlock_bh();
return tunnel;
}
@@ -1685,14 +1687,12 @@ EXPORT_SYMBOL_GPL(l2tp_tunnel_create);
/* This function is used by the netlink TUNNEL_DELETE command.
*/
-int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel)
+void l2tp_tunnel_delete(struct l2tp_tunnel *tunnel)
{
- l2tp_tunnel_inc_refcount(tunnel);
- if (false == queue_work(l2tp_wq, &tunnel->del_work)) {
- l2tp_tunnel_dec_refcount(tunnel);
- return 1;
+ if (!test_and_set_bit(0, &tunnel->dead)) {
+ l2tp_tunnel_inc_refcount(tunnel);
+ queue_work(l2tp_wq, &tunnel->del_work);
}
- return 0;
}
EXPORT_SYMBOL_GPL(l2tp_tunnel_delete);
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index a305e0c5925a..deda869504d0 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -160,6 +160,9 @@ struct l2tp_tunnel_cfg {
struct l2tp_tunnel {
int magic; /* Should be L2TP_TUNNEL_MAGIC */
+
+ unsigned long dead;
+
struct rcu_head rcu;
rwlock_t hlist_lock; /* protect session_hlist */
bool acpt_newsess; /* Indicates whether this
@@ -254,7 +257,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id,
u32 peer_tunnel_id, struct l2tp_tunnel_cfg *cfg,
struct l2tp_tunnel **tunnelp);
void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel);
-int l2tp_tunnel_delete(struct l2tp_tunnel *tunnel);
+void l2tp_tunnel_delete(struct l2tp_tunnel *tunnel);
struct l2tp_session *l2tp_session_create(int priv_size,
struct l2tp_tunnel *tunnel,
u32 session_id, u32 peer_session_id,
--
2.14.1
^ permalink raw reply related
* [net-next,RESEND] igb: add function to get maximum RSS queues
From: Zhang Shengju @ 2017-09-19 13:40 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan, netdev
This patch adds a new function igb_get_max_rss_queues() to get maximum
RSS queues, this will reduce duplicate code and facilitate future
maintenance.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
drivers/net/ethernet/intel/igb/igb.h | 1 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 32 +---------------------------
drivers/net/ethernet/intel/igb/igb_main.c | 12 +++++++++--
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 06ffb2b..ca94eff 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -684,6 +684,7 @@ void igb_ptp_rx_pktstamp(struct igb_q_vector *q_vector, void *va,
int igb_ptp_set_ts_config(struct net_device *netdev, struct ifreq *ifr);
int igb_ptp_get_ts_config(struct net_device *netdev, struct ifreq *ifr);
void igb_set_flag_queue_pairs(struct igb_adapter *, const u32);
+unsigned int igb_get_max_rss_queues(struct igb_adapter *);
#ifdef CONFIG_IGB_HWMON
void igb_sysfs_exit(struct igb_adapter *adapter);
int igb_sysfs_init(struct igb_adapter *adapter);
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index d06a8db..606e676 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -3338,37 +3338,7 @@ static int igb_set_rxfh(struct net_device *netdev, const u32 *indir,
static unsigned int igb_max_channels(struct igb_adapter *adapter)
{
- struct e1000_hw *hw = &adapter->hw;
- unsigned int max_combined = 0;
-
- switch (hw->mac.type) {
- case e1000_i211:
- max_combined = IGB_MAX_RX_QUEUES_I211;
- break;
- case e1000_82575:
- case e1000_i210:
- max_combined = IGB_MAX_RX_QUEUES_82575;
- break;
- case e1000_i350:
- if (!!adapter->vfs_allocated_count) {
- max_combined = 1;
- break;
- }
- /* fall through */
- case e1000_82576:
- if (!!adapter->vfs_allocated_count) {
- max_combined = 2;
- break;
- }
- /* fall through */
- case e1000_82580:
- case e1000_i354:
- default:
- max_combined = IGB_MAX_RX_QUEUES;
- break;
- }
-
- return max_combined;
+ return igb_get_max_rss_queues(adapter);
}
static void igb_get_channels(struct net_device *netdev,
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index ec62410..e6cc6b5 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3026,10 +3026,10 @@ static void igb_probe_vfs(struct igb_adapter *adapter)
#endif /* CONFIG_PCI_IOV */
}
-static void igb_init_queue_configuration(struct igb_adapter *adapter)
+unsigned int igb_get_max_rss_queues(struct igb_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
- u32 max_rss_queues;
+ unsigned int max_rss_queues;
/* Determine the maximum number of RSS queues supported. */
switch (hw->mac.type) {
@@ -3060,6 +3060,14 @@ static void igb_init_queue_configuration(struct igb_adapter *adapter)
break;
}
+ return max_rss_queues;
+}
+
+static void igb_init_queue_configuration(struct igb_adapter *adapter)
+{
+ u32 max_rss_queues;
+
+ max_rss_queues = igb_get_max_rss_queues(adapter);
adapter->rss_queues = min_t(u32, max_rss_queues, num_online_cpus());
igb_set_flag_queue_pairs(adapter, max_rss_queues);
--
1.8.3.1
^ permalink raw reply related
* Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")
From: Eric Dumazet @ 2017-09-19 13:51 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Eric Dumazet, David S. Miller, netdev, LKML
In-Reply-To: <20170919124503.GO4914@intel.com>
On Tue, 2017-09-19 at 15:45 +0300, Ville Syrjälä wrote:
> On Mon, Sep 18, 2017 at 12:52:15PM -0700, Eric Dumazet wrote:
> > On Mon, Sep 18, 2017 at 12:46 PM, Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> >
> > > And five months later I'm still waiting for this patch to land...
> >
> > Sure, while I was on vacation, I received thousands of emails that I
> > simply have not read.
>
> Ah that explains where my previous ping went. Pardon the snarky comment,
> and thanks for taking care of this.
>
No problem, this was my fault not following this bug.
Thanks a lot !
^ permalink raw reply
* [PATCH 1/3][v2] selftest: add a reuseaddr test
From: josef @ 2017-09-19 13:51 UTC (permalink / raw)
To: shuah, davem, netdev, linux-kselftest; +Cc: Josef Bacik
From: Josef Bacik <jbacik@fb.com>
This is to test for a regression introduced by
b9470c27607b ("inet: kill smallest_size and smallest_port")
which introduced a problem with reuseaddr and bind conflicts.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
tools/testing/selftests/net/.gitignore | 1 +
tools/testing/selftests/net/Makefile | 2 +-
tools/testing/selftests/net/reuseaddr_conflict.c | 114 +++++++++++++++++++++++
3 files changed, 116 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/net/reuseaddr_conflict.c
diff --git a/tools/testing/selftests/net/.gitignore b/tools/testing/selftests/net/.gitignore
index 9801253e4802..c612d6e38c62 100644
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@ -6,3 +6,4 @@ reuseport_bpf
reuseport_bpf_cpu
reuseport_bpf_numa
reuseport_dualstack
+reuseaddr_conflict
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index de1f5772b878..3df542c84610 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -7,7 +7,7 @@ TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetl
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket
TEST_GEN_FILES += reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
-TEST_GEN_FILES += reuseport_dualstack msg_zerocopy
+TEST_GEN_FILES += reuseport_dualstack msg_zerocopy reuseaddr_conflict
include ../lib.mk
diff --git a/tools/testing/selftests/net/reuseaddr_conflict.c b/tools/testing/selftests/net/reuseaddr_conflict.c
new file mode 100644
index 000000000000..7c5b12664b03
--- /dev/null
+++ b/tools/testing/selftests/net/reuseaddr_conflict.c
@@ -0,0 +1,114 @@
+/*
+ * Test for the regression introduced by
+ *
+ * b9470c27607b ("inet: kill smallest_size and smallest_port")
+ *
+ * If we open an ipv4 socket on a port with reuseaddr we shouldn't reset the tb
+ * when we open the ipv6 conterpart, which is what was happening previously.
+ */
+#include <errno.h>
+#include <error.h>
+#include <arpa/inet.h>
+#include <netinet/in.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <sys/socket.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+#define PORT 9999
+
+int open_port(int ipv6, int any)
+{
+ int fd = -1;
+ int reuseaddr = 1;
+ int v6only = 1;
+ int addrlen;
+ int ret = -1;
+ struct sockaddr *addr;
+ int family = ipv6 ? AF_INET6 : AF_INET;
+
+ struct sockaddr_in6 addr6 = {
+ .sin6_family = AF_INET6,
+ .sin6_port = htons(PORT),
+ .sin6_addr = in6addr_any
+ };
+ struct sockaddr_in addr4 = {
+ .sin_family = AF_INET,
+ .sin_port = htons(PORT),
+ .sin_addr.s_addr = any ? htonl(INADDR_ANY) : inet_addr("127.0.0.1"),
+ };
+
+
+ if (ipv6) {
+ addr = (struct sockaddr*)&addr6;
+ addrlen = sizeof(addr6);
+ } else {
+ addr = (struct sockaddr*)&addr4;
+ addrlen = sizeof(addr4);
+ }
+
+ if ((fd = socket(family, SOCK_STREAM, IPPROTO_TCP)) < 0) {
+ perror("socket");
+ goto out;
+ }
+
+ if (ipv6 && setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (void*)&v6only,
+ sizeof(v6only)) < 0) {
+ perror("setsockopt IPV6_V6ONLY");
+ goto out;
+ }
+
+ if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &reuseaddr,
+ sizeof(reuseaddr)) < 0) {
+ perror("setsockopt SO_REUSEADDR");
+ goto out;
+ }
+
+ if (bind(fd, addr, addrlen) < 0) {
+ perror("bind");
+ goto out;
+ }
+
+ if (any)
+ return fd;
+
+ if (listen(fd, 1) < 0) {
+ perror("listen");
+ goto out;
+ }
+ return fd;
+out:
+ close(fd);
+ return ret;
+}
+
+int main(void)
+{
+ int listenfd;
+ int fd1, fd2;
+
+ fprintf(stderr, "Opening 127.0.0.1:%d\n", PORT);
+ listenfd = open_port(0, 0);
+ if (listenfd < 0)
+ error(1, errno, "Couldn't open listen socket");
+ fprintf(stderr, "Opening INADDR_ANY:%d\n", PORT);
+ fd1 = open_port(0, 1);
+ if (fd1 >= 0)
+ error(1, 0, "Was allowed to create an ipv4 reuseport on a already bound non-reuseport socket");
+ fprintf(stderr, "Opening in6addr_any:%d\n", PORT);
+ fd1 = open_port(1, 1);
+ if (fd1 < 0)
+ error(1, errno, "Couldn't open ipv6 reuseport");
+ fprintf(stderr, "Opening INADDR_ANY:%d\n", PORT);
+ fd2 = open_port(0, 1);
+ if (fd2 >= 0)
+ error(1, 0, "Was allowed to create an ipv4 reuseport on a already bound non-reuseport socket");
+ close(fd1);
+ fprintf(stderr, "Opening INADDR_ANY:%d after closing ipv6 socket\n", PORT);
+ fd1 = open_port(0, 1);
+ if (fd1 >= 0)
+ error(1, 0, "Was allowed to create an ipv4 reuseport on an already bound non-reuseport socket with no ipv6");
+ fprintf(stderr, "Success");
+ return 0;
+}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3][v2] selftests: actually run the various net selftests
From: josef @ 2017-09-19 13:51 UTC (permalink / raw)
To: shuah, davem, netdev, linux-kselftest; +Cc: Josef Bacik
In-Reply-To: <1505829088-1823-1-git-send-email-jbacik@fb.com>
From: Josef Bacik <jbacik@fb.com>
These self tests are just self contained binaries, they are not run by
any of the scripts in the directory. This means they need to be marked
with TEST_GEN_PROGS to actually be run, not TEST_GEN_FILES.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
v1->v2:
- Moved msg_zerocopy to TEST_GEN_FILES since it's not runnable in it's current
state
tools/testing/selftests/net/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 3df542c84610..d86bca991f45 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -5,9 +5,9 @@ CFLAGS += -I../../../../usr/include/
TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
TEST_GEN_FILES = socket
-TEST_GEN_FILES += psock_fanout psock_tpacket
-TEST_GEN_FILES += reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
-TEST_GEN_FILES += reuseport_dualstack msg_zerocopy reuseaddr_conflict
+TEST_GEN_FILES += psock_fanout psock_tpacket msg_zerocopy
+TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
+TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict
include ../lib.mk
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3][v2] selftests: silence test output by default
From: josef @ 2017-09-19 13:51 UTC (permalink / raw)
To: shuah, davem, netdev, linux-kselftest; +Cc: Josef Bacik
In-Reply-To: <1505829088-1823-1-git-send-email-jbacik@fb.com>
From: Josef Bacik <jbacik@fb.com>
Some of the networking tests are very noisy and make it impossible to
see if we actually passed the tests as they run. Default to suppressing
the output from any tests run in order to make it easier to track what
failed.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
v1->v2:
- dump output into /tmp/testname instead of /dev/null
tools/testing/selftests/lib.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 693616651da5..4665463779f5 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -24,7 +24,7 @@ define RUN_TESTS
echo "selftests: Warning: file $$BASENAME_TEST is not executable, correct this.";\
echo "not ok 1..$$test_num selftests: $$BASENAME_TEST [FAIL]"; \
else \
- cd `dirname $$TEST` > /dev/null; (./$$BASENAME_TEST && echo "ok 1..$$test_num selftests: $$BASENAME_TEST [PASS]") || echo "not ok 1..$$test_num selftests: $$BASENAME_TEST [FAIL]"; cd - > /dev/null;\
+ cd `dirname $$TEST` > /dev/null; (./$$BASENAME_TEST > /tmp/$$BASENAME_TEST 2>&1 && echo "ok 1..$$test_num selftests: $$BASENAME_TEST [PASS]") || echo "not ok 1..$$test_num selftests: $$BASENAME_TEST [FAIL]"; cd - > /dev/null;\
fi; \
done;
endef
@@ -55,7 +55,7 @@ endif
define EMIT_TESTS
@for TEST in $(TEST_GEN_PROGS) $(TEST_PROGS); do \
BASENAME_TEST=`basename $$TEST`; \
- echo "(./$$BASENAME_TEST && echo \"selftests: $$BASENAME_TEST [PASS]\") || echo \"selftests: $$BASENAME_TEST [FAIL]\""; \
+ echo "(./$$BASENAME_TEST > /tmp/$$BASENAME_TEST 2>&1 && echo \"selftests: $$BASENAME_TEST [PASS]\") || echo \"selftests: $$BASENAME_TEST [FAIL]\""; \
done;
endef
--
2.7.4
^ permalink raw reply related
* Re: software interrupts close to 100 with 9000 tc filter entries
From: Eric Dumazet @ 2017-09-19 14:01 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netdev
In-Reply-To: <1627070802.486441.1505827738125@mail.libero.it>
On Tue, 2017-09-19 at 15:28 +0200, Marco Berizzi wrote:
> Hi Folks,
>
> I'm running linux 4.12.10 x86_64 on a Slackware 14.2 64bit
> as a simple 4 NIC router. Network throughput processed by
> this machine is less than 200Mbit/s
> The cpu model is Intel(R) Xeon(R) CPU 5160 @ 3.00GHz with
> 2GB ram.
>
> I need to blacklist about 9000 single ip addresses.
> This is the relevant script to blacklist these ip addresses:
>
> tc qdisc add dev eth0 ingress
> tc qdisc add dev eth1 ingress
>
> while read -r line
> do
> tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip src $line action drop
> tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src $line action drop
> done < blacklisted_ip_addresses
>
> After loading these ip addresses, the si (software interrupts)
> number shown by top is always close to 100
> If I delete the ingress qdisc on both the device, the si
> fall down to less than 5
>
> Running the same script with 'only' 700 ip addresses is
> flawless.
>
> Kindly I would like to ask if am I doing anything in
> a wrong way or if the hardware is too old for this kind
> of setup.
>
> I have selected the tc filter setup instead of netfilter
> one, because I was reading this from iproute2/doc/actions:
>
> A side effect is that we can now get stateless firewalling to work with tc..
> Essentially this is now an alternative to iptables.
> I wont go into details of my dislike for iptables at times, but.
> scalability is one of the main issues; however, if you need stateful
> classification - use netfilter (for now).
>
> Any response are welcome
> TIA
Processing a list of 700 rules per incoming packet is not wise.
Alternatives :
- netfilter with IPSET : This probably can be done with one lookup in a
table. Probably easiest way to setup.
- BPF filter (XDP or TC )
^ permalink raw reply
* RE: [PATCH net-next 5/5] tls: Add generic NIC offload infrastructure.
From: Boris Pismenny @ 2017-09-19 14:02 UTC (permalink / raw)
To: Hannes Frederic Sowa, Ilya Lesokhin
Cc: netdev@vger.kernel.org, davem@davemloft.net, davejwatson@fb.com,
tom@herbertland.com, Aviad Yehezkel, Liran Liss
In-Reply-To: <87wp4vt4aa.fsf@stressinduktion.org>
Hello,
Hannes Frederic Sowa <hannes@stressinduktion.org> writes:
> Hello,
>
> Ilya Lesokhin <ilyal@mellanox.com> writes:
>
> > Hannes Frederic Sowa <hannes@stressinduktion.org> writes:
> >
> >> The user should be aware of that they can't migrate the socket to
> >> another interface if they got hw offloaded. This is not the case for
> software offload.
> >> Thus I think the user has to opt in and it shouldn't be a heuristic
> >> until we can switch back to sw offload path.
> >>
> >> Maybe change flowi_oif to sk_bound_dev_if and somwhow lock it against
> >> further changes if hw tls is in use?
> >>
> >
> > I'm not sure I follow.
> > We do set sk->sk_bound_dev_if to prevent further changes.
> >
> > Do you recommend we enable TLS offload only if SO_BINDTODEVICE
> > was previously used on that socket?
> > and prevent even users with CAP_NET_RAW from unbinding it?
> >
> > I would rather avoid requiring CAP_NET_RAW to use TLS offload.
> > But admittedly I'm not sure setting sk->sk_bound_dev_if without
> > CAP_NET_RAW like we do is legit either.
> >
> > Finally, the reason we made HW offload the default is that the user
> > can use sudo ethtool -K enp0s4 tls-hw-tx-offload off to opt out of HW
> > offload and we currently don't have anything equivalent for opting out of
> SW KTLS.
>
> IMHO the decision if a TCP flow should be bounded to hw and thus never
> push traffic to another interface should a decision the administrator and the
> application should opt in. You might have your management application
> which is accessible over multiple interfaces and your production application
> which might want to use hw offloaded tls. Thus I don't think only a single
> ethtool knob will do it.
IMO the configuration knob should be at the kTLS level and not at the
HW vs. SW level. The management application shouldn't be using kTLS.
I'd like to view TLS offload similarly to LSO. The default is opt-in if
possible, and the Kernel decides that based on device capabilities.
>
> I agree that SO_BINDTODEVICE is bad for this use case. First, the
> CAP_NET_RAW limitation seems annoying and we don't want to enforce TLS
> apps to have this capability. Second, the user space application doesn't care
> which interface it should talk to (maybe?) but leave the routing decision to
> the kernel and just opt in to TLS. SO_BINDTODEVICE doesn't allow this.
>
> sk_bound_dev_if can be rebound later with CAP_NET_RAW privileges, will
> this be a problem?
Yes it is a problem and we have some ideas for a software fallback that should
catch this.
Is the software fallback a prerequisite for kTLS offload in Kernel?
>
> Have you thought how the user space will configure the various offloading
> features (sw, hw, none)? Will it in e.g. OpenSSL be part of the Cipher Spec or
> will there be new functions around SSL_CTX to do so?
>
> Maybe an enhancement of the TLS_TX setsockopt with a boolean for hw
> offload is a solution?
Yes, we think that OpenSSL should first configure whether it complies with
kTLS support. Next, we thought of using an environment variable to control
kTLS globally in OpenSSL as follows:
1. only software kTLS
2. only hardware kTLS - no fallback to software.
3. Try to use hardware kTLS and if it isn't supported fallback to software kTLS.
The above is something we plan for the future, assuming that kTLS wouldn't fit for
all use-cases. What do you think?
If you'd like to have more fine-grained control of kTLS, e.g. per socket,
then the application would need to be modified to configure that,
which is something we try to avoid.
>
> Another question:
>
> How is the dependency management done between socket layer and driver
> layer? It seems a bit cyclic but judging from this code you don't hold
> references to the device (dev_hold) (which is good, you don't want to have
> users creating refs to devices). OTOH you somehow need to match sockets
> from the device layer up to the socket. Will those be reference counted or
> does that work without?
Not sure I follow your question.
We use the socket from the device layer through the SKB that carries it,
so I think it should work without.
We don't attempt to perform a socket lookup or anything of this sort.
^ permalink raw reply
* RE: [PATCH net 0/7] Bug fixes for the HNS3 Ethernet Driver for Hip08 SoC
From: Salil Mehta @ 2017-09-19 14:12 UTC (permalink / raw)
To: Leon Romanovsky
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm
In-Reply-To: <20170919035900.GI5788-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
Hi Leon,
> -----Original Message-----
> From: Leon Romanovsky [mailto:leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Tuesday, September 19, 2017 4:59 AM
> To: Salil Mehta
> Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org; Zhuangyuzeng (Yisen); lipeng (Y);
> mehta.salil.lnk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm
> Subject: Re: [PATCH net 0/7] Bug fixes for the HNS3 Ethernet Driver for
> Hip08 SoC
>
> On Tue, Sep 19, 2017 at 02:06:21AM +0100, Salil Mehta wrote:
> > This patch set presents some bug fixes for the HNS3 Ethernet driver,
> identified
> > during internal testing & stabilization efforts.
> >
> > This patch series is meant for Linux 4.14 kernel.
> >
> > Lipeng (6):
> > net: hns3: get phy addr from NCL_config
> > net: hns3: fix the command used to unmap ring from vector
> > net: hns3: Fix ring and vector map command
> > net: hns3: fix a bug of set mac address
> > net: hns3: set default vlan id to PF
> > net: hns3: Fixes the premature exit of loop when matching clients
> >
> > Salil Mehta (1):
> > net: hns3: fixes the ether address copy with more appropriate API
>
> 1. The fixes patches should have Fixes line and not all of them have
> (I didn't look all patches).
> 2. Please decide on one style: fixes vs. Fixes, fix vs. Fix in the
> titles
> 3. Subject should be descriptive and usable, I don't know if it applies
> to the "fix a bug of set mac address" patch.
Yes, missed these. Will fix them. Thanks!
Salil
>
> Thanks
>
> >
> > drivers/net/ethernet/hisilicon/hns3/hnae3.c | 43 +++++-------
> ----------
> > .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 8 +++-
> > .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 20 ++++++++--
> > .../net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 7 ++--
> > 4 files changed, 35 insertions(+), 43 deletions(-)
> >
> > --
> > 2.11.0
> >
> >
--
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
* RE: [PATCH net-next 05/12] net: dsa: b53: Use a macro to define I/O operations
From: Vivien Didelot @ 2017-09-19 14:19 UTC (permalink / raw)
To: David Laight, 'Florian Fainelli', netdev@vger.kernel.org
Cc: davem@davemloft.net, andrew@lunn.ch
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD007A003@AcuExch.aculab.com>
Hi David,
David Laight <David.Laight@ACULAB.COM> writes:
> From: Florian Fainelli
>> Sent: 18 September 2017 22:41
>> Instead of repeating the same pattern: acquire mutex, read/write, release
>> mutex, define a macro: b53_build_op() which takes the type (read|write), I/O
>> size, and value (scalar or pointer). This helps with fixing bugs that could
>> exit (e.g: missing barrier, lock etc.).
> ....
>> +#define b53_build_op(type, op_size, val_type) \
>> +static inline int b53_##type##op_size(struct b53_device *dev, u8 page, \
>> + u8 reg, val_type val) \
>> +{ \
>> + int ret; \
>> + \
>> + mutex_lock(&dev->reg_mutex); \
>> + ret = dev->ops->type##op_size(dev, page, reg, val); \
>> + mutex_unlock(&dev->reg_mutex); \
>> + \
>> + return ret; \
>> }
>
> Why separate the 'type' and 'op_size' arguments since they
> are always pasted together?
For read/write48, the value type is u64.
Thanks,
Vivien
^ permalink raw reply
* RE: [PATCH net-next 05/12] net: dsa: b53: Use a macro to define I/O operations
From: Florian Fainelli @ 2017-09-19 14:29 UTC (permalink / raw)
To: Vivien Didelot, David Laight, netdev@vger.kernel.org
Cc: davem@davemloft.net, andrew@lunn.ch
In-Reply-To: <87tvzy93ew.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On September 19, 2017 7:19:35 AM PDT, Vivien Didelot <vivien.didelot@savoirfairelinux.com> wrote:
>Hi David,
>
>David Laight <David.Laight@ACULAB.COM> writes:
>
>> From: Florian Fainelli
>>> Sent: 18 September 2017 22:41
>>> Instead of repeating the same pattern: acquire mutex, read/write,
>release
>>> mutex, define a macro: b53_build_op() which takes the type
>(read|write), I/O
>>> size, and value (scalar or pointer). This helps with fixing bugs
>that could
>>> exit (e.g: missing barrier, lock etc.).
>> ....
>>> +#define b53_build_op(type, op_size, val_type) \
>>> +static inline int b53_##type##op_size(struct b53_device *dev, u8
>page, \
>>> + u8 reg, val_type val) \
>>> +{ \
>>> + int ret; \
>>> + \
>>> + mutex_lock(&dev->reg_mutex); \
>>> + ret = dev->ops->type##op_size(dev, page, reg, val); \
>>> + mutex_unlock(&dev->reg_mutex); \
>>> + \
>>> + return ret; \
>>> }
>>
>> Why separate the 'type' and 'op_size' arguments since they
>> are always pasted together?
>
>For read/write48, the value type is u64.
The way I read David's comment is that instead of calling the macro with read, 48, just combine that in a single argument: read48. I don't have a preference about that and can respin eventually.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 08/12] net: dsa: b53: Move EEE functions to b53
From: Vivien Didelot @ 2017-09-19 14:34 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: andrew, davem, Florian Fainelli
In-Reply-To: <20170919021947.8971-9-f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> Move the bcm_sf2 EEE-related functions to the b53 driver because this is shared
> code amongst Gigabit capable switch, only 5325 and 5365 are too old to support
> that.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [PATCH net-next v2 09/12] net: dsa: b53: Wire-up EEE
From: Vivien Didelot @ 2017-09-19 14:37 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: andrew, davem, Florian Fainelli
In-Reply-To: <20170919021947.8971-10-f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> Add support for enabling and disabling EEE, as well as re-negotiating it in
> .adjust_link() and in .port_enable().
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission
From: Miroslav Lichvar @ 2017-09-19 14:43 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Andre Guedes, Henrik Austad, linux-kernel,
Jesus Sanchez-Palencia, intel-wired-lan, John Stultz,
Thomas Gleixner, Anna-Maria Gleixner, David Miller
In-Reply-To: <cover.1505719061.git.rcochran@linutronix.de>
On Mon, Sep 18, 2017 at 09:41:15AM +0200, Richard Cochran wrote:
> This series is an early RFC that introduces a new socket option
> allowing time based transmission of packets. This option will be
> useful in implementing various real time protocols over Ethernet,
> including but not limited to P802.1Qbv, which is currently finding
> its way into 802.1Q.
If I understand it correctly, this also allows us to make a PTP/NTP
"one-step" clock with HW that doesn't support it directly.
> * Open questions about SO_TXTIME semantics
>
> - What should the kernel do if the dialed Tx time is in the past?
> Should the packet be sent ASAP, or should we throw an error?
Dropping the packet with an error would make more sense to me.
> - What should the timescale be for the dialed Tx time? Should the
> kernel select UTC when using the SW Qdisc and the HW time
> otherwise? Or should the socket option include a clockid_t?
I think for applications that don't (want to) bind their socket to a
specific interface it would be useful if the cmsg specified clockid_t
or maybe if_index. If the packet would be sent using a different
PHC/interface, it should be dropped.
> | | plain preempt_rt | so_txtime | txtime @ 250 us |
> |---------+------------------+---------------+-----------------|
> | min: | +1.940800e+04 | +4.720000e+02 | +4.720000e+02 |
> | max: | +7.556000e+04 | +5.680000e+02 | +5.760000e+02 |
> | pk-pk: | +5.615200e+04 | +9.600000e+01 | +1.040000e+02 |
> | mean: | +3.292776e+04 | +5.072274e+02 | +5.073602e+02 |
> | stddev: | +6.514709e+03 | +1.310849e+01 | +1.507144e+01 |
> | count: | 600000 | 600000 | 2400000 |
>
> Using so_txtime, the peak to peak jitter is about 100 nanoseconds,
Nice!
--
Miroslav Lichvar
^ permalink raw reply
* Re: [PATCH net-next v2 10/12] net: dsa: b53: Export b53_imp_vlan_setup()
From: Vivien Didelot @ 2017-09-19 14:41 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: andrew, davem, Florian Fainelli
In-Reply-To: <20170919021947.8971-11-f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> bcm_sf2 and b53 do exactly the same thing, so share that piece.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [PATCH net-next v2 11/12] net: dsa: bcm_sf2: Use SF2_NUM_EGRESS_QUEUES for CFP
From: Vivien Didelot @ 2017-09-19 14:42 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: andrew, davem, Florian Fainelli
In-Reply-To: <20170919021947.8971-12-f.fainelli@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
> The magic number 8 in 3 locations in bcm_sf2_cfp.c actually designates the
> number of switch port egress queues, so use that define instead of open-coding
> it.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE
From: Amine Kherbouche @ 2017-09-19 14:46 UTC (permalink / raw)
To: David Lamparter, netdev, bridge; +Cc: roopa, stephen
In-Reply-To: <6a538120-1941-7e81-c942-e97adeff2e3d@6wind.com>
Hi David,
What's next ? do you plan to send a v3 or should I do it ?
On 09/11/2017 10:02 AM, Amine Kherbouche wrote:
> Hi David,
>
> Do you plan to send a v3?
>
> On 21/08/2017 18:15, David Lamparter wrote:
>> Hi all,
>>
>>
>> this is an update on the earlier "[RFC net-next] VPLS support". Note
>> I've changed the subject lines on some of the patches to better reflect
>> what they really do (tbh the earlier subject lines were crap.)
>>
>> As previously, iproute2 / FRR patches are at:
>> - https://github.com/eqvinox/vpls-iproute2
>> - https://github.com/opensourcerouting/frr/commits/vpls
>> while this patchset is also available at:
>> - https://github.com/eqvinox/vpls-linux-kernel
>> (but please be aware that I'm amending and rebasing commits)
^ 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