On Tue, Nov 03, 2020 at 10:01:32PM +0100, Petr Machata wrote:
>
> Leon Romanovsky writes:
>
> > On Tue, Nov 03, 2020 at 12:05:20AM +0100, Petr Machata wrote:
> >>
> >> Leon Romanovsky writes:
> >>
> >> > On Sun, Nov 01, 2020 at 04:55:42PM -0700, David Ahern wrote:
> >> >
> >> >> yes, the rdma uti
On Mon, Nov 02, 2020 at 08:41:09AM -0700, David Ahern wrote:
> On 10/29/20 9:11 AM, Hangbin Liu wrote:
> > diff --git a/ip/ipvrf.c b/ip/ipvrf.c
> > index 33150ac2..afaf1de7 100644
> > --- a/ip/ipvrf.c
> > +++ b/ip/ipvrf.c
> > @@ -28,8 +28,14 @@
> > #include "rt_names.h"
> > #include "utils.h"
> >
On Tue, Nov 3, 2020 at 8:05 PM Andrii Nakryiko
wrote:
>
> On Tue, Nov 3, 2020 at 1:42 AM Magnus Karlsson
> wrote:
> >
> > From: Magnus Karlsson
> >
> > Fix a possible use after free in xsk_socket__delete that will happen
> > if xsk_put_ctx() frees the ctx. To fix, save the umem reference taken
>
On Wed, Nov 04, 2020 at 06:55:24AM +0100, Marek Behún wrote:
> On Tue, 3 Nov 2020 23:47:12 +0200
> Vladimir Oltean wrote:
>
> > On Tue, Nov 03, 2020 at 08:22:24PM +0100, Marek Behún wrote:
> > > Add pla_ and usb_ prefixed versions of ocp_read_* and ocp_write_*
> > > functions. This saves us from
On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
>> Thanks for providing the numbers. Do you think that dropping (up to)
>> 7 packets is acceptable?
>
> net.ipv4.tcp_syn_retries = 6
>
> tcp clients wouldn't even get that far leading to connect establish issues.
This does not really matter. If ho
On Wed, Nov 04, 2020 at 01:57:10AM +, Hayes Wang wrote:
> Marek Behún
> > Sent: Wednesday, November 4, 2020 3:22 AM
> > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> > index b1770489aca5..85dda591c838 100644
> > --- a/drivers/net/usb/r8152.c
> > +++ b/drivers/net/usb/r8152.c
On Tue, Nov 03, 2020 at 10:32:37AM -0700, David Ahern wrote:
> configure scripts usually allow you to control options directly,
> overriding the autoprobe.
What do you think of the follow update? It's a little rough and only controls
libbpf.
$ git diff
diff --git a/configure b/configure
index 711
1) Fix packet receiving of standard IP tunnels when the xfrm_interface
module is installed. From Xin Long.
2) Fix a race condition between spi allocating and hash list
resizing. From zhuoliang zhang.
Please pull or let me know if there are problems.
Thanks!
The following changes since com
From: zhuoliang zhang
we found that the following race condition exists in
xfrm_alloc_userspi flow:
user threadstate_hash_work thread
xfrm_alloc_userspi()
__find_acq_core()
/*alloc new xfrm_state:x*/
x
From: Xin Long
As Nicolas noticed in his case, when xfrm_interface module is installed
the standard IP tunnels will break in receiving packets.
This is caused by the IP tunnel handlers with a higher priority in xfrm
interface processing incoming packets by xfrm_input(), which would drop
the pack
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or member
'dev' not described in 'try_toggle_control_gpio'
drivers/net/ethernet/smsc/smc91x.c:2200: warning: Function parameter or member
'desc' not described in 'try_toggle_co
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/xilinx/xilinx_emaclite.c:525: warning: Function parameter
or member 'txqueue' not described in 'xemaclite_tx_timeout'
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Michal Simek
Cc: Shannon Nelson
Cc: Martin Habets
Cc: "Mi
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/toshiba/spider_net.c:263: warning: Function parameter or
member 'hwdescr' not described in 'spider_net_get_descr_status'
drivers/net/ethernet/toshiba/spider_net.c:263: warning: Excess function
parameter 'descr' description i
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member
'hdr_data' not described in 'build_hdr_data'
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter
or member 'irq' not described in 'gelic_card_interrupt'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter
or member 'ptr' not described i
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member
'hdr_field' not described in 'build_hdr_data'
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/ti/am65-cpts.c:736: warning: Function parameter or member
'en' not described in 'am65_cpts_rx_enable'
drivers/net/ethernet/ti/am65-cpts.c:736: warning: Excess function parameter
'skb' description in 'am65_cpts_rx_enable'
Cc
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
used [-Wunused-but-set-variable]
drivers/net/xen-netfront.c:1592: warning: Function parameter or member 'dev'
not
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/ti/am65-cpsw-qos.c:364: warning: Function parameter or
member 'ndev' not described in 'am65_cpsw_timer_set'
drivers/net/ethernet/ti/am65-cpsw-qos.c:364: warning: Function parameter or
member 'est_new' not described in 'am65_
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'dev' not described in 'frontend_changed'
drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
'frontend_state' not described in 'frontend_changed
'status' is used to interact with a hardware register. It might not
be safe to remove it entirely. Mark it as __maybe_unused instead.
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/smsc/smc911x.c: In function ‘smc911x_phy_configure’:
drivers/net/ethernet/smsc/smc911x.c:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
This is the last set.
Lee Jones (12):
net: usb: lan78x
Fixes the following W=1 kernel build warning(s):
drivers/net/usb/lan78xx.c: In function ‘lan78xx_read_raw_otp’:
drivers/net/usb/lan78xx.c:825:6: warning: variable ‘ret’ set but not used
[-Wunused-but-set-variable]
drivers/net/usb/lan78xx.c: In function ‘lan78xx_write_raw_otp’:
drivers/net/usb
From: wenxu
This one is prepare for the next patch.
Signed-off-by: wenxu
---
include/net/sch_generic.h | 5 -
net/sched/act_mirred.c| 21 +++--
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index
From: wenxu
Currently kernel tc subsystem can do conntrack in cat_ct. But when several
fragment packets go through the act_ct, function tcf_ct_handle_fragments
will defrag the packets to a big one. But the last action will redirect
mirred to a device which maybe lead the reassembly big packet ove
On Tue, 3 Nov 2020 18:45:59 -0800, Alexei Starovoitov wrote:
> libbpf is the only library I know that is backward and forward compatible.
This is great to hear. It means there will be no problem with iproute2
using the system libbpf. As libbpf is both backward and forward
compatible, iproute2 will
On 04.11.20 10:06, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
used [-Wunused-but-set-variable]
Those two warnings are not fixed by the p
On Tue, Nov 03, 2020 at 02:46:13PM -0500, Peter Xu wrote:
On Tue, Nov 03, 2020 at 05:04:23PM +0800, Jason Wang wrote:
On 2020/11/3 上午1:11, Stefano Garzarella wrote:
> On Fri, Oct 30, 2020 at 07:44:43PM +0800, Jason Wang wrote:
> >
> > On 2020/10/30 下午6:54, Stefano Garzarella wrote:
> > > On Fri
From: Mariusz Dudek
This patch series adds support for separation of eBPF program
load and xsk socket creation. In for example a Kubernetes
environment you can have an AF_XDP CNI or daemonset that is
responsible for launching pods that execute an application
From: Mariusz Dudek
Add support for separation of eBPF program load and xsk socket
creation.
This is needed for use-case when you want to privide as little
privileges as possible to the data plane application that will
handle xsk socket creation and incomi
From: Mariusz Dudek
Introduce a sample program to demonstrate the control and data
plane split. For the control plane part a new program called
xdpsock_ctrl_proc is introduced. For the data plane part, some code
was added to xdpsock_user.c to act as the data plane entity.
App
On Tue, 3 Nov 2020 19:11:45 -0800, Alexei Starovoitov wrote:
> When we release new version of libbpf it goes through rigorous testing.
> bpftool gets a lot of test coverage as well.
> iproute2 with shared libbpf will get nothing. It's the same random roll of
> dice.
"Random roll of dice" would be
On Wed, Nov 04, 2020 at 12:55:01AM +0100, Michal Kubecek wrote:
> On Tue, Nov 03, 2020 at 04:24:30PM +0200, Ido Schimmel wrote:
> >
> > I have the changes you requested here:
> > https://github.com/idosch/ethtool/commit/b34d15839f2662808c566c04eda726113e20ee59
> >
> > Do you want to integrate it
It was <2020-11-04 śro 03:42>, when Andrew Lunn wrote:
>> +config SPI_AX88796C_COMPRESSION
>> +bool "SPI transfer compression"
>> +default n
>> +depends on SPI_AX88796C
>> +help
>> + Say Y here to enable SPI transfer compression. It saves up
>> + to 24 dummy cycles during
With NETIF_F_HW_TLS_TX packets are encrypted in HW. This cannot be
logically done when HW_CSUM offload is off.
Fixes: 2342a8512a1e ("net: Add TLS TX offload features")
Signed-off-by: Tariq Toukan
Reviewed-by: Boris Pismenny
---
net/core/dev.c | 5 +
1 file changed, 5 insertions(+)
Hi,
Ple
On 11/4/20 4:11 AM, Alexei Starovoitov wrote:
On Wed, Nov 04, 2020 at 10:17:30AM +0800, Hangbin Liu wrote:
On Tue, Nov 03, 2020 at 02:55:54PM -0800, Alexei Starovoitov wrote:
The scope of bpf in iproute2 is tiny - a few tc modules (and VRF but it
does not need libbpf) which is a small subset of
Convert mvneta driver to xdp_return_frame_bulk APIs.
XDP_REDIRECT (upstream codepath): 275Kpps
XDP_REDIRECT (upstream codepath + bulking APIs): 284Kpps
Signed-off-by: Lorenzo Bianconi
---
drivers/net/ethernet/marvell/mvneta.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Convert mlx5 driver to xdp_return_frame_bulk APIs.
XDP_REDIRECT (upstream codepath): 8.5Mpps
XDP_REDIRECT (upstream codepath + bulking APIs): 10.1Mpps
Signed-off-by: Lorenzo Bianconi
---
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
XDP bulk APIs introduce a defer/flush mechanism to return
pages belonging to the same xdp_mem_allocator object
(identified via the mem.id field) in bulk to optimize
I-cache and D-cache since xdp_return_frame is usually run
inside the driver NAPI tx completion loop.
Convert mvneta, mvpp2 and mlx5 dr
Introduce the capability to batch page_pool ptr_ring refill since it is
usually run inside the driver NAPI tx completion loop.
Suggested-by: Jesper Dangaard Brouer
Signed-off-by: Lorenzo Bianconi
---
include/net/page_pool.h | 26 ++
net/core/page_pool.c| 35 +
Convert mvpp2 driver to xdp_return_frame_bulk APIs.
XDP_REDIRECT (upstream codepath): 1.79Mpps
XDP_REDIRECT (upstream codepath + bulking APIs): 1.93Mpps
Tested-by: Matteo Croce
Signed-off-by: Lorenzo Bianconi
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 5 -
1 file changed, 4 inse
XDP bulk APIs introduce a defer/flush mechanism to return
pages belonging to the same xdp_mem_allocator object
(identified via the mem.id field) in bulk to optimize
I-cache and D-cache since xdp_return_frame is usually run
inside the driver NAPI tx completion loop.
The bulk queue size is set to 16
On Wed, 4 Nov 2020 10:47:10 +0200
Vladimir Oltean wrote:
> > So you aren't complaining about the definition of pla_ and usb_
> > functions, just that they are defined via macros?
>
> Yes.
What if concatenation wasn't used, but the functions were still defined
with macro?
DEFINE_READ_FUNC(pla
Or something like this?
#define DEF_R_FUNC(_t, _r, _r_i, _mcu) \
static inline _t _r(struct r8152 *tp, u16 index)\
{ \
return _r_i(tp, _mcu, index); \
}
#define
On Wed, Nov 04, 2020 at 11:35:45AM +0100, Marek Behún wrote:
> Or something like this?
>
> #define DEF_R_FUNC(_t, _r, _r_i, _mcu)\
> static inline _t _r(struct r8152 *tp, u16 index) \
> { \
>
Hangbin Liu writes:
> On Tue, Nov 03, 2020 at 10:32:37AM -0700, David Ahern wrote:
>> configure scripts usually allow you to control options directly,
>> overriding the autoprobe.
>
> What do you think of the follow update? It's a little rough and only controls
> libbpf.
>
> $ git diff
> diff --g
On Wed, 4 Nov 2020 13:00:59 +0200
Vladimir Oltean wrote:
> On Wed, Nov 04, 2020 at 11:35:45AM +0100, Marek Behún wrote:
> > Or something like this?
> >
> > #define DEF_R_FUNC(_t, _r, _r_i, _mcu) \
> > static inline _t _r(struct r8152 *tp, u16 index)\
> >
On Wed, 4 Nov 2020 11:22:54 +0100
Lorenzo Bianconi wrote:
> XDP bulk APIs introduce a defer/flush mechanism to return
> pages belonging to the same xdp_mem_allocator object
> (identified via the mem.id field) in bulk to optimize
> I-cache and D-cache since xdp_return_frame is usually run
> insid
> On Wed, 4 Nov 2020 11:22:54 +0100
> Lorenzo Bianconi wrote:
>
[...]
> > +/* XDP bulk APIs introduce a defer/flush mechanism to return
> > + * pages belonging to the same xdp_mem_allocator object
> > + * (identified via the mem.id field) in bulk to optimize
> > + * I-cache and D-cache.
> > +
Daniel Borkmann writes:
> Back in the days when developing lib/bpf.c, it was explicitly done as
> built-in for iproute2 so that it doesn't take years for users to
> actually get to the point where they can realistically make use of it.
> If we were to extend the internal lib/bpf.c to similar feat
Zero-fill element values for all other cpus than current, just as
when not using prealloc. This is the only way the bpf program can
ensure known initial values for all cpus ('onallcpus' cannot be
set when coming from the bpf program).
The scenario is: bpf program inserts some elements in a per-cpu
On 04/11/2020 11:06, Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/ti/am65-cpts.c:736: warning: Function parameter or
member 'en' not described in 'am65_cpts_rx_enable'
drivers/net/ethernet/ti/am65-cpts.c:736: warning: Excess function parameter
'
On Wed, Nov 04, 2020 at 12:09:15PM +0100, Toke Høiland-Jørgensen wrote:
> > +usage()
> > +{
> > + cat < > +Usage: $0 [OPTIONS]
> > + -h | --help Show this usage info
> > + --no-libbpf build the package without libbpf
> > + --libbpf-dir=DIR buil
On Mon, Nov 02, 2020 at 06:19:32PM +0200, Kalle Valo wrote:
> Марков Михаил Александрович writes:
>
> > rt2800 only gives you survey for current channel.
> >
> > Survey-based ACS algorithms are failing to perform their job when working
> > with rt2800.
> >
> > Make rt2800 save survey for every ch
From: Menglong Dong
The initialization for err with 0 seems useless, as it is soon updated
with -ENOMEM. So, we can init err with -ENOMEM.
Signed-off-by: Menglong Dong
---
drivers/net/macvlan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/macvlan.c b/driver
On Wed, Nov 04, 2020 at 09:06:03AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
> 'dev' not described in 'frontend_changed'
> drivers/net/xen-netback/xenbus.c:419: warning: Function par
Hi Marco,
Thank you very much for your time reviewing and your helpful comments.
Also sorry for the late reply. Please see my responses below.
These are only my thoughts but I would be very interested to have your
feedback if you don't mind and have time for this.
I've been pulling my hair wi
>
-
Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la
Longeraie 7, 1110, Morges, Switzerland
-
-Original Message-
> From: Rob Herring
> Sent: Friday, October 30, 2020 8:19 PM
> To: Badel, Laurent
On Wed, Nov 04, 2020 at 12:10:53PM +0100, Marek Behún wrote:
> > I'm not sure it's worth the change :(
> > Let's put it another way, your diffstat has 338 insertions and 335
> > deletions. Aka you're saving 3 lines overall.
> > With this new approach that doesn't use token concatenation at all,
> >
On Wed, 4 Nov 2020 11:22:55 +0100 Lorenzo Bianconi wrote:
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ef98372facf6..236c5ed3aa66 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
[...]
> @@ -408,6 +410,39 @@ void page_pool_put_page(struct page_pool *pool, st
Add health reporters for RVU NPA block.
Only reporter dump is supported
Output:
# devlink health
pci/0002:01:00.0:
reporter npa
state healthy error 0 recover 0
# devlink health dump show pci/0002:01:00.0 reporter npa
NPA_AF_GENERAL:
Unmap PF Error: 0
Free Disabled for
Add basic devlink and devlink health reporters.
Devlink health reporters are added for NPA and NIX blocks.
These reporters report the error count in respective blocks.
Address Jakub's comment to add devlink support for error reporting.
https://www.spinics.net/lists/netdev/msg670712.html
Change-lo
On Wed, 4 Nov 2020 12:19:02 +0100
Lorenzo Bianconi wrote:
> > On Wed, 4 Nov 2020 11:22:54 +0100
> > Lorenzo Bianconi wrote:
> >
>
> [...]
>
> > > +/* XDP bulk APIs introduce a defer/flush mechanism to return
> > > + * pages belonging to the same xdp_mem_allocator object
> > > + * (identifi
Add devlink support to AF driver. Basic devlink support is added.
Currently info_get is the only supported devlink ops.
devlink ouptput looks like this
# devlink dev
pci/0002:01:00.0
# devlink dev info
pci/0002:01:00.0:
driver octeontx2-af
versions:
fixed:
mbox version: 9
Si
Add health reporters for RVU NPA block.
Only reporter dump is supported.
Output:
# ./devlink health
pci/0002:01:00.0:
reporter npa
state healthy error 0 recover 0
reporter nix
state healthy error 0 recover 0
# ./devlink health dump show pci/0002:01:00.0 reporter nix
NIX_AF_GE
On Wed, Nov 04, 2020 at 09:50:30AM +0100, Eric Dumazet wrote:
> On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
> >> Thanks for providing the numbers. Do you think that dropping (up to)
> >> 7 packets is acceptable?
> >
> > net.ipv4.tcp_syn_retries = 6
> >
> > tcp clients wouldn't even get that far
On 11/4/20 1:36 PM, Matthew Wilcox wrote:
> On Wed, Nov 04, 2020 at 09:50:30AM +0100, Eric Dumazet wrote:
>> On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
Thanks for providing the numbers. Do you think that dropping (up to)
7 packets is acceptable?
>>>
>>> net.ipv4.tcp_syn_retries = 6
> On Wed, 4 Nov 2020 12:19:02 +0100
> Lorenzo Bianconi wrote:
>
> > > On Wed, 4 Nov 2020 11:22:54 +0100
> > > Lorenzo Bianconi wrote:
> > >
> >
> > [...]
> >
> > > > +/* XDP bulk APIs introduce a defer/flush mechanism to return
> > > > + * pages belonging to the same xdp_mem_allocator obje
Packets are processed even though the first fragment don't include all
headers through the upper layer header. This breaks TAHI IPv6 Core
Conformance Test v6LC.1.3.6.
Referring to RFC8200 SECTION 4.5: "If the first fragment does not include
all headers through an Upper-Layer header, then that frag
> >> +static int
> >> +ax88796c_set_tunable(struct net_device *ndev, const struct
> >> ethtool_tunable *tuna,
> >> + const void *data)
> >> +{
> >> + struct ax88796c_device *ax_local = to_ax88796c_device(ndev);
> >> +
> >> + switch (tuna->id) {
> >> + case ETHTOOL_SPI_COMPRESSION:
> > > (ii) This defeats the purpose of a previous commit [2] that disabled
> > > the ref clock for power saving reasons. If a ref clock for the PHY is
> > > specified in DT, the SMSC driver will keep it always on (confirmed
> > > with scope).
> >
> > NACK, the clock provider can be any clock. This
On 11/4/20 12:20 PM, Toke Høiland-Jørgensen wrote:
Daniel Borkmann writes:
Back in the days when developing lib/bpf.c, it was explicitly done as
built-in for iproute2 so that it doesn't take years for users to
actually get to the point where they can realistically make use of it.
If we were to
>
-
Eaton Industries Manufacturing GmbH ~ Registered place of business: Route de la
Longeraie 7, 1110, Morges, Switzerland
-
-Original Message-
> From: Andrew Lunn
> Sent: Wednesday, November 04, 2020 2:11 PM
> To: Badel, Lau
On Wed, Nov 04, 2020 at 09:06:00AM +, Lee Jones wrote:
> 'status' is used to interact with a hardware register. It might not
> be safe to remove it entirely. Mark it as __maybe_unused instead.
Hi Lee
https://www.mail-archive.com/netdev@vger.kernel.org/msg365875.html
I'm working on driver/n
On Wed, Nov 04, 2020 at 09:05:59AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/usb/lan78xx.c: In function ‘lan78xx_read_raw_otp’:
> drivers/net/usb/lan78xx.c:825:6: warning: variable ‘ret’ set but not used
> [-Wunused-but-set-variable]
> drivers/n
On Wed, Nov 04, 2020 at 09:06:01AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/ethernet/xilinx/xilinx_emaclite.c:525: warning: Function
> parameter or member 'txqueue' not described in 'xemaclite_tx_timeout'
https://www.spinics.net/lists/netdev/msg
On Wed, Nov 04, 2020 at 09:06:03AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member
> 'dev' not described in 'frontend_changed'
> drivers/net/xen-netback/xenbus.c:419: warning: Function par
From: Ido Schimmel
This patch set adds support for nexthop objects offload with a dummy
implementation over netdevsim. mlxsw support will be added later.
The general idea is very similar to route offload in that notifications
are sent whenever nexthop objects are changed. A listener can veto the
From: Ido Schimmel
Prepare the new notification information so that it could be passed to
listeners in the new patch.
Changes since RFC:
* Add a blank line in __nh_notifier_single_info_init()
Signed-off-by: Ido Schimmel
Reviewed-by: David Ahern
---
net/ipv4/nexthop.c | 109 ++
From: Ido Schimmel
The flag indicates to user space that the nexthop is not programmed to
forward packets in hardware, but rather to trap them to the CPU. This is
needed, for example, when the MAC of the nexthop neighbour is not
resolved and packets should reach the CPU to trigger neighbour
resol
From: Ido Schimmel
Add a function that can be called by device drivers to set "offload" or
"trap" indication on nexthops following nexthop notifications.
Changes since RFC:
* s/nexthop_hw_flags_set/nexthop_set_hw_flags/
Signed-off-by: Ido Schimmel
---
include/net/nexthop.h | 1 +
net/ipv4/ne
From: Ido Schimmel
The next patch will add extack to the notification info. This allows
listeners to veto notifications and communicate the reason to user space.
Signed-off-by: Ido Schimmel
Reviewed-by: David Ahern
---
net/ipv4/nexthop.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions
From: Ido Schimmel
Add data structures that will be used for nexthop replace and delete
notifications in the previously introduced nexthop notification chain.
New data structures are added instead of passing the existing nexthop
code structures directly for several reasons.
First, the existing
From: Ido Schimmel
Implement dummy nexthop "offload" in the driver by storing currently
"programmed" nexthops in a hash table. Each nexthop in the hash table is
marked with "trap" indication and increments the nexthops resource
occupancy.
This will later allow us to test the nexthop offload API
From: Ido Schimmel
Previous patches added the ability to program nexthop objects.
Therefore, no longer forbid the programming of routes that point to such
objects.
Signed-off-by: Ido Schimmel
Reviewed-by: David Ahern
---
drivers/net/netdevsim/fib.c | 10 --
1 file changed, 10 deletion
From: Ido Schimmel
The Spectrum ASIC has a dedicated table where nexthops (i.e., adjacency
entries) are populated. The size of this table can be controlled via
devlink-resource.
Add such a resource to netdevsim so that its occupancy will reflect the
number of nexthop objects currently programmed
From: Ido Schimmel
This will be used by the next patch which extends the function to replay
all the existing nexthops to the notifier block being registered.
Device drivers will be able to pass extack to the function since it is
passed to them upon reload from devlink.
Signed-off-by: Ido Schimm
From: Ido Schimmel
Emit a notification in the nexthop notification chain when a new nexthop
is added (not replaced). The nexthop can either be a new group or a
single nexthop.
The notification is sent after the nexthop is inserted into the
red-black tree, as listeners might need to callback into
From: Ido Schimmel
When a single nexthop is deleted, the configuration of all the groups
using the nexthop is effectively modified. In this case, emit a
notification in the nexthop notification chain for each modified group
so that listeners would not need to keep track of which nexthops are
memb
From: Ido Schimmel
When registering a new notifier to the nexthop notification chain,
replay all the existing nexthops to the new notifier so that it will
have a complete picture of the available nexthops.
Signed-off-by: Ido Schimmel
---
net/ipv4/nexthop.c | 54
From: Ido Schimmel
The notification is emitted after all the validation checks were
performed, but before the new configuration (i.e., 'struct nh_info') is
pointed at by the old shell (i.e., 'struct nexthop'). This prevents the
need to perform rollback in case the notification is vetoed.
The nex
From: Ido Schimmel
Convert the sole listener of the nexthop notification chain (the VXLAN
driver) to the new notification info.
Signed-off-by: Ido Schimmel
---
drivers/net/vxlan.c | 9 +++--
net/ipv4/nexthop.c | 2 +-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/
From: Ido Schimmel
When a single nexthop is replaced, the configuration of all the groups
using the nexthop is effectively modified. In this case, emit a
notification in the nexthop notification chain for each modified group
so that listeners would not need to keep track of which nexthops are
mem
From: Ido Schimmel
Emit a notification in the nexthop notification chain when an existing
nexthop group is replaced.
The notification is emitted after all the validation checks were
performed, but before the new configuration (i.e., 'struct nh_grp') is
pointed at by the old shell (i.e., 'struct
From: Ido Schimmel
Remove in-kernel route notifications when the configuration of their
nexthop changes.
These notifications are unnecessary because the route still uses the
same nexthop ID. A separate notification for the nexthop change itself
is now sent in the nexthop notification chain.
Sig
From: Ido Schimmel
Test various aspects of the nexthop offload API on top of the netdevsim
implementation. Both good and bad flows are tested.
Signed-off-by: Ido Schimmel
---
.../drivers/net/netdevsim/nexthop.sh | 436 ++
1 file changed, 436 insertions(+)
create mode
On Wed, Nov 04, 2020 at 09:06:04AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/ethernet/ti/am65-cpsw-qos.c:364: warning: Function parameter or
> member 'ndev' not described in 'am65_cpsw_timer_set'
> drivers/net/ethernet/ti/am65-cpsw-qos.c:364: war
On Wed, Nov 04, 2020 at 09:06:06AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/xen-netfront.c: In function ‘store_rxbuf’:
> drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not
> used [-Wunused-but-set-variable]
> drivers/net
On Wed, Nov 04, 2020 at 09:06:07AM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> from drivers/net/ethernet/ibm/ibmvnic.c:35:
> inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
> drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Functio
Hi,
On Wed, Nov 04, 2020 at 02:01:28PM +0100, Georg Kohmann wrote:
> Packets are processed even though the first fragment don't include all
> headers through the upper layer header. This breaks TAHI IPv6 Core
> Conformance Test v6LC.1.3.6.
>
> Referring to RFC8200 SECTION 4.5: "If the first fragm
1 - 100 of 394 matches
Mail list logo
