[net PATCH v2] net: sched, fix OOO packets with pfifo_fast

After the qdisc lock was dropped in pfifo_fast we allow multiple enqueue threads and dequeue threads to run in parallel. On the enqueue side the skb bit ooo_okay is used to ensure all related skbs are enqueued in-order. On the dequeue side though there is no similar logic. What we observe is with

Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.

On Sat, Mar 24, 2018 at 07:48:58PM +0100, Andrew Lunn wrote: > As far as i can see, you have three basic problems: > > 1) How do you associate the PTP device to the netdev? > 2) How do you get the information you need to configure the PTP device Yes, yes. > 3) How do you limit the MAC/PHY to

RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path

> -Original Message- > From: Michael Kelley (EOSG) > Sent: Saturday, March 24, 2018 12:48 PM > To: Haiyang Zhang ; da...@davemloft.net; > netdev@vger.kernel.org > Cc: KY Srinivasan ; Stephen Hemminger > ; o...@aepfle.de;

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

Thadeu Lima de Souza Cascardo writes: > On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: >> Register callback to collect hardware/firmware dumps in second kernel >> before hardware/firmware is initialized. The dumps for each device >> will be available

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: > Register callback to collect hardware/firmware dumps in second kernel > before hardware/firmware is initialized. The dumps for each device > will be available under /sys/kernel/crashdd/cxgb4/ directory in second > kernel. > >

[PATCH net-next 5/6] r8169: change type of driver_data

Several functions accessing the device driver_data field don't need the net_device. All needed parameters can be accessed via struct rtl8169_private, therefore change type of driver_data accordingly. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c |

[PATCH net-next 3/6] r8169: change argument type of PHY-related functions

Some PHY-related functions functions can be a little streamlined and simplified by taking a struct rtl8169_private * argument. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 23 ++- 1 file changed, 10 insertions(+), 13

[PATCH net-next 6/6] r8169: change argument type of rtl8169_net_suspend and __rtl8169_resume

Both functions can be simplified by changing the argument type to struct rtl8169_private *. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 26 +++--- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git

[PATCH net-next 4/6] r8169: change argument type of interrupt handler

The interrupt handler doesn't need the net_device, therefore change the argument type to struct rtl8169_private *. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH net-next 1/6] r8169: change argument type of callback hw_start in struct rtl8169_private

Change argument type of callback hw_start to be more in line with the other callbacks and to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 41 +--- 1 file changed, 15 insertions(+), 26

[PATCH net-next 2/6] r8169: change argument type of counter functions

These counter functions don't deal with the net_device, so change the argument type to struct rtl8169_private *. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 32 +--- 1 file changed, 13 insertions(+), 19 deletions(-)

[PATCH net-next 0/6] r8169: patch set with further smaller improvements

Patch set with further changes w/o functional change aiming at streamlining and simplifying the code. Heiner Kallweit (6): r8169: change argument type of callback hw_start in struct rtl8169_private r8169: change argument type of counter functions r8169: change argument type of PHY-related

Re: [net PATCH] net: sched, fix OOO packets with pfifo_fast

On 03/24/2018 02:15 PM, Eric Dumazet wrote: > > > On 03/24/2018 01:13 PM, John Fastabend wrote: >> After the qdisc lock was dropped in pfifo_fast we allow multiple >> enqueue threads and dequeue threads to run in parallel. On the >> enqueue side the skb bit ooo_okay is used to ensure all related

Re: switchdev and dsa

> I use older kernel (2.6), because these is the Linux from provider chip (TI). TI really only provides 2.6? I strongly suggest you choose a different SoC vendor. > Is there an example maybe for this which someone can provide ?

Re: [net PATCH] net: sched, fix OOO packets with pfifo_fast

On 03/24/2018 01:13 PM, John Fastabend wrote: > After the qdisc lock was dropped in pfifo_fast we allow multiple > enqueue threads and dequeue threads to run in parallel. On the > enqueue side the skb bit ooo_okay is used to ensure all related > skbs are enqueued in-order. On the dequeue side

Re: switchdev and dsa

On Sat, Mar 24, 2018 at 11:51 PM, Andrew Lunn wrote: > On Sat, Mar 24, 2018 at 11:35:38PM +0300, Ran Shalit wrote: >> On Sat, Mar 24, 2018 at 10:02 PM, Andrew Lunn wrote: >> > On Sat, Mar 24, 2018 at 07:12:15PM +0300, Ran Shalit wrote: >> >> Hello, >> >> >> >> I

Re: [PATCH 0/7] Netfilter fixes for net

From: Pablo Neira Ayuso Date: Sat, 24 Mar 2018 21:34:16 +0100 > The following patchset contains Netfilter fixes for your net tree, > they are: ... > You can pull these changes from: > > git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git Pulled, thank you.

[PATCH] net: qmi_wwan: add BroadMobi BM806U 2020:2033

BroadMobi BM806U is an Qualcomm MDM9225 based 3G/4G modem. Tested hardware BM806U is mounted on D-Link DWR-921-C3 router. The USB id is added to qmi_wwan.c to allow QMI communication with the BM806U. Tested on 4.14 kernel and OpenWRT. Signed-off-by: Pawel Dembicki ---

Re: switchdev and dsa

On Sat, Mar 24, 2018 at 11:35:38PM +0300, Ran Shalit wrote: > On Sat, Mar 24, 2018 at 10:02 PM, Andrew Lunn wrote: > > On Sat, Mar 24, 2018 at 07:12:15PM +0300, Ran Shalit wrote: > >> Hello, > >> > >> I am new with switchdev and dsa. > >> I would please like to ask if configuring

Re: switchdev and dsa

On Sat, Mar 24, 2018 at 10:02 PM, Andrew Lunn wrote: > On Sat, Mar 24, 2018 at 07:12:15PM +0300, Ran Shalit wrote: >> Hello, >> >> I am new with switchdev and dsa. >> I would please like to ask if configuring a device tree/board file >> with a switch (for example marvell switch)

[PATCH 5/7] netfilter: nf_tables: cache device name in flowtable object

Devices going away have to grab the nfnl_lock from the netdev event path to avoid races with control plane updates. However, netlink dumps in netfilter do not hold nfnl_lock mutex. Cache the device name into the objects to avoid an use-after-free situation for a device that is going away.

[PATCH 1/7] netfilter: nf_tables: meter: pick a set backend that supports updates

From: Florian Westphal in nftables, 'meter' can be used to instantiate a hash-table at run time: rule add filter forward iif "internal" meter hostacct { ip saddr counter} nft list meter ip filter hostacct table ip filter { meter hostacct { type ipv4_addr elements = {

[PATCH 4/7] netfilter: drop template ct when conntrack is skipped.

From: Paolo Abeni The ipv4 nf_ct code currently skips the nf_conntrak_in() call for fragmented packets. As a results later matches/target can end up manipulating template ct entry instead of 'real' ones. Exploiting the above, syzbot found a way to trigger the following splat:

[PATCH 2/7] netfilter: nf_tables: permit second nat hook if colliding hook is going away

From: Florian Westphal Sergei Trofimovich reported that restoring an nft ruleset doesn't work anymore unless old rule content is flushed first. The problem stems from a recent change designed to prevent multiple nat hooks at the same hook point locations and nftables transaction

[PATCH 0/7] Netfilter fixes for net

Hi David, The following patchset contains Netfilter fixes for your net tree, they are: 1) Don't pick fixed hash implementation for NFT_SET_EVAL sets, otherwise userspace hits EOPNOTSUPP with valid rules using the meter statement, from Florian Westphal. 2) If you send a batch that flushes

[PATCH 7/7] netfilter: nf_socket: Fix out of bounds access in nf_sk_lookup_slow_v{4,6}

From: Subash Abhinov Kasiviswanathan skb_header_pointer will copy data into a buffer if data is non linear, otherwise it will return a pointer in the linear section of the data. nf_sk_lookup_slow_v{4,6} always copies data of size udphdr but later accesses memory within

[PATCH 6/7] netfilter: nf_tables: do not hold reference on netdevice from preparation phase

The netfilter netdevice event handler hold the nfnl_lock mutex, this avoids races with a device going away while such device is being attached to hooks from the netlink control plane. Therefore, either control plane bails out with ENOENT or netdevice event path waits until the hook that is

[PATCH 3/7] netfilter: nf_tables: add missing netlink attrs to policies

From: Florian Westphal Fixes: 8aeff920dcc9 ("netfilter: nf_tables: add stateful object reference to set elements") Fixes: f25ad2e907f1 ("netfilter: nf_tables: prepare for expressions associated to set elements") Fixes: 1a94e38d254b ("netfilter: nf_tables: add NFTA_RULE_ID

Re: [PATCH 0/2] sh_eth: unify the SoC feature checks

On 03/24/2018 11:14 PM, Sergei Shtylyov wrote: > Should have been 0/5 in the subject. Sorry. :-) Oh, and I forgot 'net-next' inside [], sorry again! :-)

Re: [PATCH 4/5] sh_eth: add sh_eth_cpu_data::no_tx_cntr flag

Should read no_tx_cntrs in the subject -- forgot tp update it when renaming the flag...

Re: [PATCH 0/2] sh_eth: unify the SoC feature checks

Should have been 0/5 in the subject. Sorry. :-)

[net PATCH] net: sched, fix OOO packets with pfifo_fast

After the qdisc lock was dropped in pfifo_fast we allow multiple enqueue threads and dequeue threads to run in parallel. On the enqueue side the skb bit ooo_okay is used to ensure all related skbs are enqueued in-order. On the dequeue side though there is no similar logic. What we observe is with

[PATCH 5/5] sh_eth: add sh_eth_cpu_data::cexcr flag

GEther controllers have CERCR/CEECR instead of CNDCR on the others. Currently we are calling sh_eth_is_gether() in order to check for this, however it would be simpler to check the new 'cexcr' bitfield in the 'struct sh_eth_cpu_data'; then we'd be able to remove sh_eth_is_gether() as there would

[PATCH 4/5] sh_eth: add sh_eth_cpu_data::no_tx_cntr flag

RZ/A1H (R7S72100) Ether controller doesn't seem to have the TX counter registers like TROCR/CDCR/LCCR (or at least they are still undocumented like some TSU registers), so we bail out of sh_eth_get_stats() early in this case. Currently we are calling sh_eth_is_rz_fast_ether() in order to check

[PATCH 3/5] sh_eth: add sh_eth_cpu_data::xdfar_rw flag

The GEther-like controllers have writeable RDFAR/TDFAR, on the others they are read-only or just absent (on R-Car). Currently we are calling sh_eth_is_{gether|rz_fast_ether}() in order to check if these registers can be written to, however it would be simpler to check the new 'xdfar_rw' bitfield

[PATCH 0/2] sh_eth: unify the SoC feature checks

Hello! Here's a set of 5 patches against DaveM's 'net-next.git' repo. The Ether driver sometimes uses the bit fields in 'struct sh_eth_cpu_data' to check which Ether registers exist in a certain SoC and sometimes it uses sh_eth_is_{gether|rz_fast_ether}() which basically compares 2 pointers (1

[PATCH 2/5] sh_eth: add sh_eth_cpu_data::edtrr_trns value

sh_eth_get_edtrr_trns() returns the value to be written to EDTRR in order to start TX DMA -- this value is different between the GEther-like and the other controllers. We can replace this function (and thus get rid of the calls to sh_eth_is_{gether|rz_fast_ether}() by it) with a new field

[PATCH 1/5] sh_eth: add sh_eth_cpu_data::soft_reset() method

sh_eth_reset() performs a software reset which is implemented in a completely different way for the GEther-like controllers vs the other controllers due to a different layout of EDMR (and other factors) -- it therefore makes sense to convert this function to a mandatory

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

On 24/03/2018 12:00, Andrew Lunn wrote: > root@zii-devel-b:~# ./iproute2/devlink/devlink port > mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0 > mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1 > mdio_bus/0.1:00/2: type eth

Re: switchdev and dsa

On Sat, Mar 24, 2018 at 07:12:15PM +0300, Ran Shalit wrote: > Hello, > > I am new with switchdev and dsa. > I would please like to ask if configuring a device tree/board file > with a switch (for example marvell switch) will provide all ports > behins the switch as valid interface (ethX) ports in

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

> >> >root@zii-devel-b:~# ./iproute2/devlink/devlink port > >> >mdio_bus/0.1:00/0: type eth netdev lan0 flavour physical number 0 > >> >mdio_bus/0.1:00/1: type eth netdev lan1 flavour physical number 1 > >> >mdio_bus/0.1:00/2: type eth netdev lan2 flavour physical number 2 >

Re: [PATCH] of_net: Implement of_get_nvmem_mac_address helper

> A quick survey for the of_get_mac_address users learns that most of them do > a memcpy (or similar) right after it, so for these drivers the > "of_get_nvmem_mac_address" style signature that performs the memcpy (or > better, ether_addr_copy) is a better fit, e.g.: > > int

Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.

On Sat, Mar 24, 2018 at 10:12:19AM -0700, Richard Cochran wrote: > On Thu, Mar 22, 2018 at 12:50:07AM +0100, Andrew Lunn wrote: > > How clever is this device? Can it tell the difference between > > 1000Base-X and SGMII? Can it figure out that the MAC is repeating > > every bit 100 times and so has

[PATCH bpf-next 0/2] bpf_verifier_log changes

This patch set has some changes and clean-up works for the bpf_verifier_log. They are the prep works for the BTF (BPF Type Format). Martin KaFai Lau (2): bpf: Rename bpf_verifer_log bpf: Add bpf_verifier_vlog() and bpf_verifier_log_needed() include/linux/bpf_verifier.h | 13 ++---

[PATCH bpf-next 1/2] bpf: Rename bpf_verifer_log

bpf_verifer_log => bpf_verifier_log Signed-off-by: Martin KaFai Lau Acked-by: Alexei Starovoitov --- include/linux/bpf_verifier.h | 6 +++--- kernel/bpf/verifier.c| 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH bpf-next 2/2] bpf: Add bpf_verifier_vlog() and bpf_verifier_log_needed()

The BTF (BPF Type Format) verifier needs to reuse the current BPF verifier log. Hence, it requires the following changes: (1) Expose log_write() in verifier.c for other users. Its name is renamed to bpf_verifier_vlog(). (2) The BTF verifier also needs to check 'log->level && log->ubuf &&

[iproute PATCH 0/3] ss: Allow excluding a socket table from being queried

The first patch in this series adds the new functionality, the remaining two refactor the code a bit. Phil Sutter (3): ss: Allow excluding a socket table from being queried ss: Put filter DB parsing into a separate function ss: Drop filter_default_dbs() man/man8/ss.8 | 8 +++- misc/ss.c

[iproute PATCH 1/3] ss: Allow excluding a socket table from being queried

The original problem was that a simple call to 'ss' leads to loading of sctp_diag kernel module which might not be desired. While searching for a workaround, it became clear how inconvenient it is to exclude a single socket table from being queried. This patch allows to prefix an item passed to

[iproute PATCH 3/3] ss: Drop filter_default_dbs()

Instead call filter_db_parse(..., "all"). This eliminates the duplicate default DB definition. Signed-off-by: Phil Sutter --- misc/ss.c | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/misc/ss.c b/misc/ss.c index e6511014ba3f4..ab2f07b9e5d4d

[iproute PATCH 2/3] ss: Put filter DB parsing into a separate function

Use a table for database name parsing. The tricky bit is to allow for association of a (nearly) arbitrary number of DBs with each name. Luckily the number is not fully arbitrary as there is an upper bound of MAX_DB items. Since it is not possible to have a variable length array inside a variable

[iproute PATCH] ssfilter: Eliminate shift/reduce conflicts

The problematic bit was the 'expr: expr expr' rule. Fix this by making 'expr' token represent a single filter only and introduce a new token 'exprlist' to represent a combination of filters. Signed-off-by: Phil Sutter --- misc/ssfilter.y | 52

Re: [PATCH bpf] nfp: bpf: fix check of program max insn count

On Fri, Mar 23, 2018 at 08:00:13PM -0700, Jakub Kicinski wrote: > NFP program allocation length is in bytes and NFP program length > is in instructions, fix the comparison of the two. > > Fixes: 9314c442d7dd ("nfp: bpf: move translation prepare to offload.c") > Signed-off-by: Jakub Kicinski

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

Sat, Mar 24, 2018 at 06:07:27PM CET, f.faine...@gmail.com wrote: >On March 24, 2018 9:07:49 AM PDT, Jiri Pirko wrote: >>Sat, Mar 24, 2018 at 03:35:09PM CET, f.faine...@gmail.com wrote: >>>On March 24, 2018 12:45:51 AM PDT, Jiri Pirko >>wrote: Fri, Mar 23,

Re: [PATCH bpf] tools: bpftool: don't use hex numbers in JSON output

On Fri, Mar 23, 2018 at 07:45:12PM -0700, Jakub Kicinski wrote: > JSON does not accept hex numbers with 0x prefix. Simply print > as decimal numbers, JSON should be primarily machine-readable. > > Signed-off-by: Jakub Kicinski > Reviewed-by: Quentin Monnet

Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.

On Thu, Mar 22, 2018 at 12:50:07AM +0100, Andrew Lunn wrote: > How clever is this device? Can it tell the difference between > 1000Base-X and SGMII? Can it figure out that the MAC is repeating > every bit 100 times and so has dropped to 10Mbits? Does it understand > EEE? Does it need to know if

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

On March 24, 2018 9:07:49 AM PDT, Jiri Pirko wrote: >Sat, Mar 24, 2018 at 03:35:09PM CET, f.faine...@gmail.com wrote: >>On March 24, 2018 12:45:51 AM PDT, Jiri Pirko >wrote: >>>Fri, Mar 23, 2018 at 04:24:12PM CET, and...@lunn.ch wrote: On Fri, Mar 23, 2018

Re: [PATCH net-next RFC V1 3/5] net: Introduce field for the MII time stamper.

On Wed, Mar 21, 2018 at 12:12:00PM -0700, Florian Fainelli wrote: > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > > index 5fbb9f1da7fd..223d691aa0b0 100644 > > --- a/include/linux/netdevice.h > > +++ b/include/linux/netdevice.h > > @@ -1943,6 +1943,7 @@ struct net_device {

Re: [PATCH net-next RFC V1 2/5] net: phy: Move time stamping interface into the generic mdio layer.

On Wed, Mar 21, 2018 at 02:45:13PM -0700, Richard Cochran wrote: > On Wed, Mar 21, 2018 at 12:10:07PM -0700, Florian Fainelli wrote: > > > + phydev->mdio.ts_info = dp83640_ts_info; > > > + phydev->mdio.hwtstamp = dp83640_hwtstamp; > > > + phydev->mdio.rxtstamp = dp83640_rxtstamp; > > > +

RE: [PATCH net-next,1/2] hv_netvsc: Fix the return status in RX path

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Haiyang Zhang > Sent: Thursday, March 22, 2018 12:01 PM > To: da...@davemloft.net; netdev@vger.kernel.org > Cc: Haiyang Zhang ; KY Srinivasan >

Re: [PATCH] of_net: Implement of_get_nvmem_mac_address helper

On 23-03-18 20:33, Florian Fainelli wrote: On 03/23/2018 12:20 PM, Mike Looijmans wrote: On 23-3-2018 16:11, Andrew Lunn wrote: On Fri, Mar 23, 2018 at 03:24:34PM +0100, Mike Looijmans wrote: It's common practice to store MAC addresses for network interfaces into nvmem devices. However the

switchdev and dsa

Hello, I am new with switchdev and dsa. I would please like to ask if configuring a device tree/board file with a switch (for example marvell switch) will provide all ports behins the switch as valid interface (ethX) ports in userspace ifconfig command ? Thank you, ranran

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

Sat, Mar 24, 2018 at 03:35:09PM CET, f.faine...@gmail.com wrote: >On March 24, 2018 12:45:51 AM PDT, Jiri Pirko wrote: >>Fri, Mar 23, 2018 at 04:24:12PM CET, and...@lunn.ch wrote: >>>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote: Fri, Mar 23, 2018 at 02:43:57PM

Re: [PATCH RFC v2 net-next 19/21] net/ipv6: separate handling of FIB entries from dst based routes

On Sat, Mar 24, 2018 at 09:31:02AM -0600, David Ahern wrote: > On 3/24/18 8:31 AM, Ido Schimmel wrote: > > On Sun, Mar 18, 2018 at 08:36:20PM -0700, David Ahern wrote: > >> @@ -405,18 +383,9 @@ static void ip6_dst_destroy(struct dst_entry *dst) > >>rt->rt6i_idev = NULL; > >>

Re: [PATCH] of_net: Implement of_get_nvmem_mac_address helper

On 23-03-18 20:42, Andrew Lunn wrote: Indeed. I'll add my settings as an example. Where should I put this documentation, in the commit comment or somewhere in Documents/devicetree/bindings? Documention/devicetree/bindings/net/ethernet.txt Ok It's what I intended to do, but there were two

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

Sat, Mar 24, 2018 at 03:40:02PM CET, and...@lunn.ch wrote: >> >The hardware and mechanical engineer is free to wire switch ports to >> >the front panel however they want. That is why we put the netdev name >> >in device tree. >> >> Got it. Hmm, so I think that the port number can be made optional

Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink

Sat, Mar 24, 2018 at 04:05:38PM CET, d...@cumulusnetworks.com wrote: >On 3/24/18 1:26 AM, Jiri Pirko wrote: >> Fri, Mar 23, 2018 at 04:13:14PM CET, d...@cumulusnetworks.com wrote: >>> On 3/23/18 9:05 AM, Jiri Pirko wrote: Fri, Mar 23, 2018 at 04:03:40PM CET, d...@cumulusnetworks.com wrote:

Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path

On Sat, Mar 24, 2018 at 09:28:01AM -0600, David Ahern wrote: > On 3/24/18 9:05 AM, Ido Schimmel wrote: > > On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote: > >> This set is the first of many changes to improve the scalability of the > >> IPv6 code. Follow on changes include: > >> -

Re: [PATCH RFC v2 net-next 19/21] net/ipv6: separate handling of FIB entries from dst based routes

On 3/24/18 8:31 AM, Ido Schimmel wrote: > On Sun, Mar 18, 2018 at 08:36:20PM -0700, David Ahern wrote: >> @@ -405,18 +383,9 @@ static void ip6_dst_destroy(struct dst_entry *dst) >> rt->rt6i_idev = NULL; >> in6_dev_put(idev); >> } >> -bucket =

Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path

On 3/24/18 9:05 AM, Ido Schimmel wrote: > On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote: >> This set is the first of many changes to improve the scalability of the >> IPv6 code. Follow on changes include: >> - consolidating duplicate fib6_info references like IPv4 does with >>

Re: [PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy writes: > On production servers running variety of workloads over time, kernel > panic can happen sporadically after days or even months. It is > important to collect as much debug logs as possible to root cause > and fix the problem, that may not

Re: [PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

On Sat, Mar 24, 2018 at 04:26:34PM +0530, Rahul Lakkireddy wrote: > Register callback to collect hardware/firmware dumps in second kernel > before hardware/firmware is initialized. The dumps for each device > will be available under /sys/kernel/crashdd/cxgb4/ directory in second > kernel. > >

Re: [net-next 03/15] net/mlx5e: PFC stall prevention support

On Fri, Mar 23, 2018 at 03:39:13PM -0700, Saeed Mahameed wrote: > From: Inbar Karmy > > Implement set/get functions to configure PFC stall prevention > timeout by tunables api through ethtool. > By default the stall prevention timeout is configured to 8 sec. > Timeout range

Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink

On 3/24/18 1:26 AM, Jiri Pirko wrote: > Fri, Mar 23, 2018 at 04:13:14PM CET, d...@cumulusnetworks.com wrote: >> On 3/23/18 9:05 AM, Jiri Pirko wrote: >>> Fri, Mar 23, 2018 at 04:03:40PM CET, d...@cumulusnetworks.com wrote: On 3/23/18 9:01 AM, Jiri Pirko wrote: > Fri, Mar 23, 2018 at

Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path

On Sun, Mar 18, 2018 at 08:36:01PM -0700, David Ahern wrote: > This set is the first of many changes to improve the scalability of the > IPv6 code. Follow on changes include: > - consolidating duplicate fib6_info references like IPv4 does with > duplicate fib_info Before that you need to

Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink

On 3/23/18 9:47 PM, Jakub Kicinski wrote: > On Thu, 22 Mar 2018 15:57:57 -0700, David Ahern wrote: >> From: David Ahern >> >> Add devlink support to netdevsim and use it to implement a simple, >> profile based resource controller. Only one controller is needed >> per namespace,

Re: [PATCH v5 3/5] bnx2x: Eliminate duplicate barriers on weakly-ordered archs

On 3/24/2018 10:30 AM, Chopra, Manish wrote: >> -Original Message- >> From: Sinan Kaya [mailto:ok...@codeaurora.org] >> Sent: Friday, March 23, 2018 10:44 PM >> To: David Miller >> Cc: netdev@vger.kernel.org; ti...@codeaurora.org; sulr...@codeaurora.org; >>

Re: [net-next 02/15] ethtool: Add support for configuring PFC stall prevention in ethtool

On Fri, Mar 23, 2018 at 03:39:12PM -0700, Saeed Mahameed wrote: > From: Inbar Karmy > > In the event where the device unexpectedly becomes unresponsive > for a long period of time, flow control mechanism may propagate > pause frames which will cause congestion spreading to

Re: [PATCH net-next 6/8] MIPS: mscc: Add switch to ocelot

On Fri, Mar 23, 2018 at 03:11:23PM -0700, Florian Fainelli wrote: > On 03/23/2018 03:06 PM, Andrew Lunn wrote: > >>> That is the trade off of having a standalone MDIO bus driver. Maybe > >>> add a phandle to the internal MDIO bus? The switch driver could then > >>> follow the phandle, and direct

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

> >The hardware and mechanical engineer is free to wire switch ports to > >the front panel however they want. That is why we put the netdev name > >in device tree. > > Got it. Hmm, so I think that the port number can be made optional and > when it is present, it would be used to generate

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

On March 24, 2018 12:45:51 AM PDT, Jiri Pirko wrote: >Fri, Mar 23, 2018 at 04:24:12PM CET, and...@lunn.ch wrote: >>On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote: >>> Fri, Mar 23, 2018 at 02:43:57PM CET, and...@lunn.ch wrote: >>> >> I tested this for mlxsw and nfp. I

Re: [PATCH RFC v2 net-next 19/21] net/ipv6: separate handling of FIB entries from dst based routes

On Sun, Mar 18, 2018 at 08:36:20PM -0700, David Ahern wrote: > @@ -405,18 +383,9 @@ static void ip6_dst_destroy(struct dst_entry *dst) > rt->rt6i_idev = NULL; > in6_dev_put(idev); > } > - bucket = rcu_dereference_protected(rt->rt6i_exception_bucket, 1); > -

RE: [PATCH v5 3/5] bnx2x: Eliminate duplicate barriers on weakly-ordered archs

> -Original Message- > From: Sinan Kaya [mailto:ok...@codeaurora.org] > Sent: Friday, March 23, 2018 10:44 PM > To: David Miller > Cc: netdev@vger.kernel.org; ti...@codeaurora.org; sulr...@codeaurora.org; > linux-arm-...@vger.kernel.org;

Re: [bug, bisected] pfifo_fast causes packet reordering

On 03/22/2018 03:16 AM, Jakob Unterwurzacher wrote: > On 21.03.18 21:52, John Fastabend wrote: >> Can you try this, >> >> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h >> index d4907b5..1e596bd 100644 >> --- a/include/net/sch_generic.h >> +++ b/include/net/sch_generic.h >> @@

RE: [RFC PATCH net-next] tipc: tipc_disc_addr_trial_msg() can be static

Acked-by: Jon Maloy jon.ma...@ericsson.com Thanks, Fengguang > -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of kbuild test robot > Sent: Friday, March 23, 2018 15:48 > To: Jon Maloy > Cc:

Re: [PATCH 2/4] wireless: Use octal not symbolic permissions

On Sat, 2018-03-24 at 12:09 +0200, Kalle Valo wrote: > Joe Perches writes: > > Prefer the direct use of octal for permissions. [] > I don't know what tree are you planning to send these to, but I would > prefer to take this to wireless-drivers-next to minimise any conflicts.

Re: [PATCH net-next 1/2] fs/crashdd: add API to collect hardware dump in second kernel

Hi Rahul, 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/Rahul-Lakkireddy/fs-crashdd-add-API-to-collect-hardware-dump-in-second-kernel/20180324-193856 config: i386-randconfig-n0-201811 (attached

pull-request: wireless-drivers-next 2018-03-24

Hi Dave, here's the first pull request to net-next for 4.17. What's special here is the addition of a new bluetooth driver, but that's been acked by Marcel. Also we add a new include file to include/net because of that. Please let me know if you have any problems. Kalle The following changes

Re: [PATCH net-next 1/2] fs/crashdd: add API to collect hardware dump in second kernel

Hi Rahul, 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/Rahul-Lakkireddy/fs-crashdd-add-API-to-collect-hardware-dump-in-second-kernel/20180324-193856 config: i386-randconfig-s0-201811 (attached

pull-request: wireless-drivers 2018-03-24

Hi Dave, This is a pull request to the net tree for 4.16. I'm not planning to send anything more in this cycle for 4.16, unless something really major comes up. Please let me know if you have any problems. Kalle The following changes since commit 87de1201ddaa39d4f3fafa9f35ac143e582517e6:

[PATCH net-next v2 2/2] cxgb4: collect hardware dump in second kernel

Register callback to collect hardware/firmware dumps in second kernel before hardware/firmware is initialized. The dumps for each device will be available under /sys/kernel/crashdd/cxgb4/ directory in second kernel. Signed-off-by: Rahul Lakkireddy Signed-off-by:

[PATCH net-next v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel

On production servers running variety of workloads over time, kernel panic can happen sporadically after days or even months. It is important to collect as much debug logs as possible to root cause and fix the problem, that may not be easy to reproduce. Snapshot of underlying hardware/firmware

[PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

Add a new module crashdd that exports the /sys/kernel/crashdd/ directory in second kernel, containing collected hardware/firmware dumps. The sequence of actions done by device drivers to append their device specific hardware/firmware logs to /sys/kernel/crashdd/ directory are as follows: 1.

Re: [net 7/8] net/mlx5e: Avoid using the ipv6 stub in the TC offload neigh update path

Hello! On 3/24/2018 1:05 AM, Saeed Mahameed wrote: From: Or Gerlitz Currently we use the global ipv6_stub var to access the ipv6 global nd table. This practice gets us to troubles when the stub is only partially set e.g when ipv6 is loaded under the disabled policy. In

Re: [B.A.T.M.A.N.] [PATCH][next] batman-adv: don't pass a NULL hard_iface to batadv_hardif_put

On Freitag, 23. März 2018 23:53:50 CET Colin King wrote: > From: Colin Ian King > > In the case where hard_iface is NULL, the error path may pass a null > pointer to batadv_hardif_put causing a null pointer dereference error. > Avoid this by only calling the function if

Re: [patch net-next RFC 00/12] devlink: introduce port flavours and common phys_port_name generation

Fri, Mar 23, 2018 at 04:24:12PM CET, and...@lunn.ch wrote: >On Fri, Mar 23, 2018 at 03:59:35PM +0100, Jiri Pirko wrote: >> Fri, Mar 23, 2018 at 02:43:57PM CET, and...@lunn.ch wrote: >> >> I tested this for mlxsw and nfp. I have no way to test this on DSA hw, >> >> I would really appretiate DSA

Re: [patch net-next RFC 10/12] nfp: flower: create port for flower vnic

Sat, Mar 24, 2018 at 04:32:02AM CET, jakub.kicin...@netronome.com wrote: >On Fri, 23 Mar 2018 07:29:41 +0100, Jiri Pirko wrote: >> >This will associate the PF netdev with physical port, incl. all ethtool >> >information. Im not sure we want to do that. phy_repr carries this >> >functionality.

Re: [patch net-next RFC 04/12] dsa: set devlink port attrs for dsa ports

Fri, Mar 23, 2018 at 06:09:29PM CET, f.faine...@gmail.com wrote: >On 03/23/2018 07:49 AM, Jiri Pirko wrote: >> Fri, Mar 23, 2018 at 02:30:02PM CET, and...@lunn.ch wrote: >>> On Thu, Mar 22, 2018 at 11:55:14AM +0100, Jiri Pirko wrote: From: Jiri Pirko Set the

Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink

Fri, Mar 23, 2018 at 04:13:14PM CET, d...@cumulusnetworks.com wrote: >On 3/23/18 9:05 AM, Jiri Pirko wrote: >> Fri, Mar 23, 2018 at 04:03:40PM CET, d...@cumulusnetworks.com wrote: >>> On 3/23/18 9:01 AM, Jiri Pirko wrote: Fri, Mar 23, 2018 at 03:31:02PM CET, d...@cumulusnetworks.com wrote: