> On Sat, 16 Mar 2019 13:24:39 +0800
> Zhiqiang Liu wrote:
>
>> I have updated the commit message as suggested by Eric. Even though I have
>> read
>> Documentation/networking/netdev-FAQ.rst as you mentioned. I am now still a
>> little
>> confused about the subject-prefix of v3 (net or net-next)
On Sat, 16 Mar 2019 13:24:39 +0800
Zhiqiang Liu wrote:
> I have updated the commit message as suggested by Eric. Even though I have
> read
> Documentation/networking/netdev-FAQ.rst as you mentioned. I am now still a
> little
> confused about the subject-prefix of v3 (net or net-next).
It's "ne
:
> On Fri, 15 Mar 2019 14:26:10 -0700
> Eric Dumazet wrote:
>
>> On 03/15/2019 02:08 PM, Stefano Brivio wrote:
>>> On Fri, 15 Mar 2019 11:56:01 -0700
>>> Eric Dumazet wrote:
>>>
On 03/15/2019 11:02 AM, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 15 Mar 2019 09:06:25
>>> On 03/15/2019 08:28 AM, Stefano Brivio wrote:
On Fri, 15 Mar 2019 23:18:52 +0800
Zhiqiang Liu wrote:
NACK, please read my and Eric's comments to v1 -- giving me more than 23
minutes to answer would have been a nice touch as well :)
>>>
>>> Sorry for the con
Hi Petr
> +enum rtnl_link_down_reason_major {
> + RTNL_LDR_OTHER,
Does 'other' make any sense? Seem better to just not report anything
at all, or add a comment that more reasons should be added at the end
to reflect whatever the hardware or software can determine.
> + RTNL_LDR_NO_CABLE,
On Fri, 15 Mar 2019 17:56:07 +, Petr Machata wrote:
> diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h
> index e2091bb2b3a8..cfd9e86ff0ca 100644
> --- a/include/net/rtnetlink.h
> +++ b/include/net/rtnetlink.h
> @@ -110,6 +110,9 @@ struct rtnl_link_ops {
> int
> The party with visibility into details of this process is the driver.
Hi Petr
In the general case, i would disagree with this. It is the PHY layer
which knows about these things. phylib and phylink. The MAC driver has
no idea, it just sees that the carrier is off.
There are however some driver
On Wed, Mar 13, 2019 at 09:30:02AM -0700, Brendan Gregg wrote:
> On Tue, Mar 12, 2019 at 9:54 AM Kris Van Hees
> wrote:
> >
> > On Mon, Mar 11, 2019 at 11:03:10PM -0700, Brendan Gregg wrote:
> > > On Mon, Mar 11, 2019 at 8:24 PM Kris Van Hees
> > > wrote:
> > > >
> > > > On Mon, Mar 11, 2019 at
On Fri, 15 Mar 2019 22:12:13 +, Parav Pandit wrote:
> > On Fri, 15 Mar 2019 21:08:14 +0100, Jiri Pirko wrote:
> > > >> IIUC, Jiri/Jakub are proposing creation of 2 devlink objects for
> > > >> each port - host facing ports and switch facing ports. This is in
> > > >> addition to the netdevs t
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix a umem memory leak on cleanup in AF_XDP, from Björn.
2) Fix BTF to properly resolve forward-declared enums into their corresponding
full enum definition types during deduplication, fro
On 03/13/2019 03:15 PM, Björn Töpel wrote:
> From: Björn Töpel
>
> When the umem is cleaned up, the task that created it might already be
> gone. If the task was gone, the xdp_umem_release function did not free
> the pages member of struct xdp_umem.
>
> It turned out that the task lookup was not
Similarly to commit a7603ac1fc8c ("geneve: change NET_UDP_TUNNEL
dependency to select"), GTP has a dependency on NET_UDP_TUNNEL which
makes impossible to compile it if no other protocol depending on
NET_UDP_TUNNEL is selected.
Fix this by changing the depends to a select, and drop NET_IP_TUNNEL fr
From: Eric Dumazet
Date: Thu, 14 Mar 2019 20:19:47 -0700
> Same reasons than the ones explained in commit 4179cb5a4c92
> ("vxlan: test dev->flags & IFF_UP before calling netif_rx()")
>
> netif_rx_ni() or napi_gro_frags() must be called under a strict contract.
>
> At device dismantle phase, cor
From: Pedro Tammela
Date: Thu, 14 Mar 2019 10:45:23 -0300
> Adds missing sphinx documentation to the
> socket.c's functions. Also fixes some whitespaces.
>
> I also changed the style of older documentation as an
> effort to have an uniform documentation style.
>
> Signed-off-by: Pedro Tammela
On 15.03.2019 23:09, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 21:46 +0100, Heiner Kallweit wrote:
>> On 15.03.2019 21:40, Alexander Duyck wrote:
>>> On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
On 15.03.2019 21:09, VDR User wrote:
> Thanks for the additional info and
> -Original Message-
> From: Jakub Kicinski
> Sent: Friday, March 15, 2019 3:45 PM
> To: Jiri Pirko
> Cc: Parav Pandit ; Samudrala, Sridhar
> ; da...@davemloft.net;
> netdev@vger.kernel.org; oss-driv...@netronome.com
> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on dev
On Fri, 2019-03-15 at 21:46 +0100, Heiner Kallweit wrote:
> On 15.03.2019 21:40, Alexander Duyck wrote:
> > On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
> > > On 15.03.2019 21:09, VDR User wrote:
> > > > > > > > Thanks for the additional info and for testing 4.20.15.
> > > > > > > > To
On Fri, 15 Mar 2019 14:26:10 -0700
Eric Dumazet wrote:
> On 03/15/2019 02:08 PM, Stefano Brivio wrote:
> > On Fri, 15 Mar 2019 11:56:01 -0700
> > Eric Dumazet wrote:
> >
> >> On 03/15/2019 11:02 AM, David Miller wrote:
> >>> From: Eric Dumazet
> >>> Date: Fri, 15 Mar 2019 09:06:25 -0700
>
> -Original Message-
> From: Jiri Pirko
> Sent: Friday, March 15, 2019 3:08 PM
> To: Parav Pandit
> Cc: Samudrala, Sridhar ; Jakub Kicinski
> ; da...@davemloft.net;
> netdev@vger.kernel.org; oss-driv...@netronome.com
> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on dev
On 3/15/19 1:52 AM, Phil Reid wrote:
> G'day All,
>
> I've just update from kernel 4.19 to 5.0 on a custom board that has a
> marvell
> dsa mv88e6085 and the phy on the mv88e6085 will only connect at 10Mb/s with
> the above mentioned patch applied.
>
> Bisecting the issue lead me to the following
On 3/15/19 2:16 PM, Leandro Dorileo wrote:
> The Time Aware Priority Scheduler is heavily dependent to link speed,
> it relies on it to calculate transmission bytes per cycle, we can't
> properly calculate the so called budget if the device has failed
> to report the link speed.
>
> In that case w
On 03/15/2019 02:08 PM, Stefano Brivio wrote:
> On Fri, 15 Mar 2019 11:56:01 -0700
> Eric Dumazet wrote:
>
>> On 03/15/2019 11:02 AM, David Miller wrote:
>>> From: Eric Dumazet
>>> Date: Fri, 15 Mar 2019 09:06:25 -0700
>>>
On 03/15/2019 08:28 AM, Stefano Brivio wrote:
The Time Aware Priority Scheduler is heavily dependent to link speed,
it relies on it to calculate transmission bytes per cycle, we can't
properly calculate the so called budget if the device has failed
to report the link speed.
In that case we can't dequeue packets assuming a wrong budget.
This p
The Credit Based Shaper heavily depends on link speed to calculate
the scheduling credits, we can't properly calculate the credits if the
device has failed to report the link speed.
In that case we can't dequeue packets assuming a wrong port rate that will
result into an inconsistent credit distri
This set fixes miscalculations based on invalid link speed values.
Changes in v3:
+ yep pr_info() format warnings;
Changes in v2:
+ fixed pr_info() format both on cbs and taprio patches;
Leandro Dorileo (2):
net/sched: taprio: fix picos_per_byte miscalculation
net/sched: cbs: fix port_rate
On Fri, 15 Mar 2019 11:56:01 -0700
Eric Dumazet wrote:
> On 03/15/2019 11:02 AM, David Miller wrote:
> > From: Eric Dumazet
> > Date: Fri, 15 Mar 2019 09:06:25 -0700
> >
> >>
> >>
> >> On 03/15/2019 08:28 AM, Stefano Brivio wrote:
> >>> On Fri, 15 Mar 2019 23:18:52 +0800
> >>> Zhiqiang Liu
On 3/12/19 10:41 AM, Nikolay Aleksandrov wrote:
> Hi,
> This set adds json output support to the xstats API (patch 01) and then
> adds json support to the bridge xstats output (patch 02) and adds xstats
> output support (both plain text and json) for the bonding (patch 03).
> It doesn't change the
On 15.03.2019 21:40, Alexander Duyck wrote:
> On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
>> On 15.03.2019 21:09, VDR User wrote:
>>> Thanks for the additional info and for testing 4.20.15.
>>> To rule out that the issue is caused by a regression in network or
>>> some oth
On Fri, 15 Mar 2019 21:08:14 +0100, Jiri Pirko wrote:
> >> IIUC, Jiri/Jakub are proposing creation of 2 devlink objects for each port
> >> -
> >> host facing ports and switch facing ports. This is in addition to the
> >> netdevs
> >> that are created today.
To be clear I'm not in favour of the d
On Thu, Mar 14, 2019 at 05:28:58PM -0700, Peter Oskolkov wrote:
> This helper is useful if a bpf tc filter sets skb->tstamp.
>
> Signed-off-by: Peter Oskolkov
pls resubmit when bpf-next reopens.
On Thu, Mar 14, 2019 at 11:39:46AM +, Lorenz Bauer wrote:
> This series adds the necessary helpers to determine wheter a given
> (encapsulated) TCP packet belongs to a connection known to the network stack.
>
> * bpf_skc_lookup_tcp gives access to request and timewait sockets
> * bpf_tcp_check
On Fri, 2019-03-15 at 21:26 +0100, Heiner Kallweit wrote:
> On 15.03.2019 21:09, VDR User wrote:
> > > > > > Thanks for the additional info and for testing 4.20.15.
> > > > > > To rule out that the issue is caused by a regression in network or
> > > > > > some other subsystem: Can you take the r816
On 15.03.2019 21:09, VDR User wrote:
> Thanks for the additional info and for testing 4.20.15.
> To rule out that the issue is caused by a regression in network or
> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> it on top of 5.0?
> Meanwhile I'll look at
On Fri, 15 Mar 2019 16:48:00 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 15, 2019 at 07:41:35PM +, Quentin Monnet escreveu:
> > 2019-03-15 12:16 UTC-0700 ~ Jakub Kicinski
> > > On Fri, 15 Mar 2019 15:41:41 -0300, Arnaldo Carvalho de Melo wrote:
> > > > While developing 'perf trace
Fri, Mar 15, 2019 at 04:32:24PM CET, pa...@mellanox.com wrote:
>
>
>> -Original Message-
>> From: Samudrala, Sridhar
>> Sent: Friday, March 15, 2019 12:58 AM
>> To: Parav Pandit ; Jakub Kicinski
>>
>> Cc: Jiri Pirko ; da...@davemloft.net;
>> netdev@vger.kernel.org; oss-driv...@netronome.c
On Fri, 15 Mar 2019 16:51:42 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Mar 15, 2019 at 12:16:32PM -0700, Jakub Kicinski escreveu:
> > Please do keep the current model of name val, IOW dump map *name* pids..
>
> I don't have a problem with that, but what would be the problem with
> support
> > >> Thanks for the additional info and for testing 4.20.15.
> > >> To rule out that the issue is caused by a regression in network or
> > >> some other subsystem: Can you take the r8169.c from 4.20.15 and test
> > >> it on top of 5.0?
> > >> Meanwhile I'll look at the changes in the driver betwe
Em Fri, Mar 15, 2019 at 12:16:32PM -0700, Jakub Kicinski escreveu:
> Please do keep the current model of name val, IOW dump map *name* pids..
I don't have a problem with that, but what would be the problem with
supporting both:
bpftool map dump name pids_filtered
and:
bpftool map dump pids_
This patch is a part of a series that extends arm64 kernel ABI to allow to
pass tagged user pointers (with the top byte set to something else other
than 0x00) as syscall arguments.
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get
Em Fri, Mar 15, 2019 at 07:41:35PM +, Quentin Monnet escreveu:
> 2019-03-15 12:16 UTC-0700 ~ Jakub Kicinski
> > On Fri, 15 Mar 2019 15:41:41 -0300, Arnaldo Carvalho de Melo wrote:
> > > While developing 'perf trace' and looking at BPF maps it puts in place I
> > > noticed that one needs to fir
2019-03-15 12:16 UTC-0700 ~ Jakub Kicinski
On Fri, 15 Mar 2019 15:41:41 -0300, Arnaldo Carvalho de Melo wrote:
While developing 'perf trace' and looking at BPF maps it puts in place I
noticed that one needs to first use 'bpftool map' to lookup a map id to
then use 'bpftool map dump map id '.
T
On Fri, 15 Mar 2019 15:41:41 -0300, Arnaldo Carvalho de Melo wrote:
> While developing 'perf trace' and looking at BPF maps it puts in place I
> noticed that one needs to first use 'bpftool map' to lookup a map id to
> then use 'bpftool map dump map id '.
>
> This is needed because everytime we re
On 03/15/2019 11:02 AM, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 15 Mar 2019 09:06:25 -0700
>
>>
>>
>> On 03/15/2019 08:28 AM, Stefano Brivio wrote:
>>> On Fri, 15 Mar 2019 23:18:52 +0800
>>> Zhiqiang Liu wrote:
>>>
In vxlan_destroy_tunnels func, unregister_netdevice_queue i
While developing 'perf trace' and looking at BPF maps it puts in place I
noticed that one needs to first use 'bpftool map' to lookup a map id to
then use 'bpftool map dump map id '.
This is needed because everytime we restart 'perf trace' the map IDs
gets changed so we need to do the ID lookup aga
From: Eric Dumazet
Date: Fri, 15 Mar 2019 09:06:25 -0700
>
>
> On 03/15/2019 08:28 AM, Stefano Brivio wrote:
>> On Fri, 15 Mar 2019 23:18:52 +0800
>> Zhiqiang Liu wrote:
>>
>>> In vxlan_destroy_tunnels func, unregister_netdevice_queue is called after
>>> gro_cells_destroy func. However, in un
From: Stefano Brivio
Date: Fri, 15 Mar 2019 16:28:24 +0100
> On Fri, 15 Mar 2019 23:18:52 +0800
> Zhiqiang Liu wrote:
>
>> In vxlan_destroy_tunnels func, unregister_netdevice_queue is called after
>> gro_cells_destroy func. However, in unregister_netdevice_queue func, the
>> gro_cells_destroy f
In general, after a port is put administratively up, certain handshake
protocols have to finish successfully, otherwise the port is left in a
NO-CARRIER or DORMANT state. When that happens, it would be useful to
communicate the reasons to the administrator, so that the problem that
prevents the lin
The PDDR register enables to read the Phy debug database.
Signed-off-by: Petr Machata
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h
b/drivers/net/ethernet/mellanox/mlxs
In order to provide visibility into problems with bringing a link up,
add rtnl_link_ops. Add the mandatory kind field. Add two new functions,
mlxsw_sp_port_link_down_reason_get_size() to calculate the size
necessary for the link-down reason attributes, and
mlxsw_sp_port_fill_link_down_reason() to f
In general, after a port is put administratively up, certain handshake
protocols have to finish successfully, otherwise the port is left in a
NO-CARRIER or DORMANT state. When that happens, it would be useful to
communicate the reasons to the administrator, so that the problem that
prevents the lin
rose_write_internal() uses a temp buffer of 100 bytes, but a manual
inspection showed that given arbitrary input, rose_create_facilities()
can fill up to 110 bytes.
Lets use a tailroom of 256 bytes for peace of mind, and remove
the bounce buffer : we can simply allocate a big enough skb
and adjust
On Fri, Mar 15, 2019 at 9:52 AM Martin Lau wrote:
>
> On Thu, Mar 14, 2019 at 05:28:58PM -0700, Peter Oskolkov wrote:
> > This helper is useful if a bpf tc filter sets skb->tstamp.
> >
> For the patch,
> Acked-by: Martin KaFai Lau
>
> Not sure if it should belong to bpf-next material though.
Tha
On Thu, Mar 14, 2019 at 05:28:58PM -0700, Peter Oskolkov wrote:
> This helper is useful if a bpf tc filter sets skb->tstamp.
>
For the patch,
Acked-by: Martin KaFai Lau
Not sure if it should belong to bpf-next material though.
Ik dacht dat het onmogelijk was https://tiotacentloc1977.blogspot.no/
On 03/15/2019 08:28 AM, Stefano Brivio wrote:
> On Fri, 15 Mar 2019 23:18:52 +0800
> Zhiqiang Liu wrote:
>
>> In vxlan_destroy_tunnels func, unregister_netdevice_queue is called after
>> gro_cells_destroy func. However, in unregister_netdevice_queue func, the
>> gro_cells_destroy func will als
> -Original Message-
> From: Samudrala, Sridhar
> Sent: Friday, March 15, 2019 12:58 AM
> To: Parav Pandit ; Jakub Kicinski
>
> Cc: Jiri Pirko ; da...@davemloft.net;
> netdev@vger.kernel.org; oss-driv...@netronome.com
> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on dev
On Fri, 15 Mar 2019 23:18:52 +0800
Zhiqiang Liu wrote:
> In vxlan_destroy_tunnels func, unregister_netdevice_queue is called after
> gro_cells_destroy func. However, in unregister_netdevice_queue func, the
> gro_cells_destroy func will also call the gro_cells_destroy func as the
> following routi
On Fri, 15 Mar 2019 22:55:52 +0800
Zhiqiang Liu wrote:
> > On Fri, 15 Mar 2019 18:06:45 +0800
> > Zhiqiang Liu wrote:
> >
> >> From: "Suanming.Mou"
> >>
> >> With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit.
> >
> > Thanks for cleaning this up.
> >
> > I think it would be n
In vxlan_destroy_tunnels func, unregister_netdevice_queue is called after
gro_cells_destroy func. However, in unregister_netdevice_queue func, the
gro_cells_destroy func will also call the gro_cells_destroy func as the
following routine:
unregister_netdevice_many() -> rollback_registered_many()
->
> On Fri, 15 Mar 2019 18:06:45 +0800
> Zhiqiang Liu wrote:
>
>> From: "Suanming.Mou"
>>
>> With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit.
>
> Thanks for cleaning this up.
>
> I think it would be nice if you could actually explain in the commit
> message why this makes the call
On 03/15/2019 03:06 AM, Zhiqiang Liu wrote:
> From: "Suanming.Mou"
>
> With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit.
>
> Fixes: ad6c9986bcb6 ("vxlan: Fix GRO cells race condition between receive and
> link delete")
>
This is a net-next candidate .
The Fixes: tag is not n
在 2019/3/13 上午1:50, Daniel Mack 写道:
On 12/3/2019 1:27 PM, Heiko Stuebner wrote:
Hi Andrew, Heiner,
Am Montag, 4. März 2019, 21:06:30 CET schrieb Andrew Lunn:
On Mon, Mar 04, 2019 at 11:30:25AM -0800, David Miller wrote:
From: Heiner Kallweit
Date: Sun, 3 Mar 2019 19:58:57 +0100
Currentl
On Fri, 15 Mar 2019 18:06:45 +0800
Zhiqiang Liu wrote:
> From: "Suanming.Mou"
>
> With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit.
Thanks for cleaning this up.
I think it would be nice if you could actually explain in the commit
message why this makes the call in vxlan_destroy_
action m_connmark returns error messages identifying itself as the
'simple' action instead of 'connmark' action. e.g.
tc filter add dev eth0 protocol all u32 match u32 0 0 flowid 1:1 \
action connmark index wrong
simple: Illegal "index"
bad action parsing
parse_action: bad value (3:connmar
which
From: "Suanming.Mou"
With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit.
Fixes: ad6c9986bcb6 ("vxlan: Fix GRO cells race condition between receive and
link delete")
Signed-off-by: Suanming.Mou
---
drivers/net/vxlan.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
G'day All,
I've just update from kernel 4.19 to 5.0 on a custom board that has a marvell
dsa mv88e6085 and the phy on the mv88e6085 will only connect at 10Mb/s with
the above mentioned patch applied.
Bisecting the issue lead me to the following patch.
d6ab93364734bd (net: phy: marvell: Avoid un
Thu, Mar 14, 2019 at 11:09:45PM CET, jakub.kicin...@netronome.com wrote:
>On Thu, 14 Mar 2019 08:38:40 +0100, Jiri Pirko wrote:
>> Wed, Mar 13, 2019 at 05:55:55PM CET, jakub.kicin...@netronome.com wrote:
>> >On Wed, 13 Mar 2019 17:22:43 +0100, Jiri Pirko wrote:
>> >> Wed, Mar 13, 2019 at 05:17:31
68 matches
Mail list logo
