This is a new feature defined in section 5 of rfc7829: "Primary Path
Switchover". By introducing a new tunable parameter:
Primary.Switchover.Max.Retrans (PSMR)
The primary path will be changed to another active path when the path
error counter on the old primary path exceeds PSMR, so that "the
Section 7.2 of rfc7829: "Peer Address Thresholds (SCTP_PEER_ADDR_THLDS)
Socket Option" extends 'struct sctp_paddrthlds' with 'spt_pathcpthld'
added to allow a user to change ps_retrans per sock/asoc/transport, as
other 2 paddrthlds: pf_retrans, pathmaxrxt.
Note: to not break the user's program, he
This is a sockopt defined in section 7.3 of rfc7829: "Exposing
the Potentially Failed Path State", by which users can change
pf_expose per sock and asoc.
v1->v2:
- no change.
v2->v3:
- return -EINVAL if params.assoc_value > SCTP_PF_EXPOSE_MAX.
- define SCTP_EXPOSE_PF_STATE SCTP_EXPOSE_POTENT
As said in rfc7829, section 3, point 12:
The SCTP stack SHOULD expose the PF state of its destination
addresses to the ULP as well as provide the means to notify the
ULP of state transitions of its destination addresses from
active to PF, and vice versa. However, it is recommended that
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is
SCTP-PF was implemented based on a Internet-Draft in 2012:
https://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
It's been updated quite a few by rfc7829 in 2016.
This patchset adds the following features:
1. add SCTP_ADDR_POTENTIALLY_FAILED notification
2. add pf_expose per ne
On Fri, Oct 11, 2019 at 11:56 PM Martin Lau wrote:
>
> On Fri, Oct 11, 2019 at 10:54:13AM -0700, Wei Wang wrote:
> > On Fri, Oct 11, 2019 at 8:42 AM Ido Schimmel wrote:
> > >
> > > On Fri, Oct 11, 2019 at 09:36:51AM -0500, Jesse Hathaway wrote:
> > > > On Thu, Oct 10, 2019 at 3:31 AM Ido Schimmel
On Sun, Oct 13, 2019 at 12:09:43PM -0700, Pravin Shelar wrote:
> On Thu, Oct 10, 2019 at 12:07 PM Guillaume Nault wrote:
> >
> > In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
> > rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
> > but there are a few path
The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
in the micrel PHY driver, it is used even with the KSZ87xx switch. This
is wrong, since the KSZ8051 configures registers of the PHY which are
not present
The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches.
Update the PHY ID and name to reflect that, as this family of switches
is commonly refered to as KSZ87xx
Signed-off-by: Marek Vasut
Cc: Andrew Lunn
Cc: David S. Miller
Cc: Florian Fainelli
Cc: George McCollister
Cc: Heine
From: Marek Vasut
Date: Sun, 13 Oct 2019 22:29:31 +0200
> On 10/13/19 10:15 PM, Heiner Kallweit wrote:
>> On 13.10.2019 21:34, Marek Vasut wrote:
>>> The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
>>> same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHY
Hi Vinicius,
On Sat, 12 Oct 2019 at 00:28, Vinicius Costa Gomes
wrote:
>
> Hi,
>
> Murali Karicheri writes:
>
> > Hi Vinicius,
> >
> > On 10/11/2019 04:12 PM, Vinicius Costa Gomes wrote:
> >> Hi Murali,
> >>
> >> Murali Karicheri writes:
> >>
> >>> Hi,
> >>>
> >>> I am testing the taprio (802.1
On 10/13/2019 1:29 PM, Marek Vasut wrote:
> On 10/13/19 10:15 PM, Heiner Kallweit wrote:
>> On 13.10.2019 21:34, Marek Vasut wrote:
>>> The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
>>> same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
>>> in the
On 10/13/19 10:15 PM, Heiner Kallweit wrote:
> On 13.10.2019 21:34, Marek Vasut wrote:
>> The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
>> same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
>> in the micrel PHY driver, it is used even with the KSZ87xx
On 10/13/19 1:17 PM, Vito Caputo wrote:
>
> Except there are examples under net/core of precisely this pattern, e.g.:
>
>
We do not care about having consistent code styles.
linux kernel has been contributed by thousands.
Each contributor has its own preferences.
We do not want to enforce
On Sun, Oct 13, 2019 at 12:58:04PM -0700, Eric Dumazet wrote:
>
>
> On 10/12/19 5:30 PM, Vito Caputo wrote:
> > Return directly from all switch cases, no point in storing in err.
> >
> > Signed-off-by: Vito Caputo
> > ---
> > net/core/skbuff.c | 15 +++
> > 1 file changed, 3 insert
On 13.10.2019 21:34, Marek Vasut wrote:
> The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
> same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
> in the micrel PHY driver, it is used even with the KSZ87xx switch. This
> is wrong, since the KSZ8051 config
On 10/12/19 5:30 PM, Vito Caputo wrote:
> Return directly from all switch cases, no point in storing in err.
>
> Signed-off-by: Vito Caputo
> ---
> net/core/skbuff.c | 15 +++
> 1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.
The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
in the micrel PHY driver, it is used even with the KSZ87xx switch. This
is wrong, since the KSZ8051 configures registers of the PHY which are
not present
The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches.
Update the PHY ID and name to reflect that, as this family of switches
is commonly refered to as KSZ87xx
Signed-off-by: Marek Vasut
Cc: Andrew Lunn
Cc: David S. Miller
Cc: Florian Fainelli
Cc: George McCollister
Cc: Heine
The KSZ87xx driver calls mutex_init() on mutexes already inited in
ksz_common.c ksz_switch_register(). Do not do it twice, drop the
reinitialization.
Signed-off-by: Marek Vasut
Cc: Andrew Lunn
Cc: David S. Miller
Cc: Florian Fainelli
Cc: George McCollister
Cc: Tristram Ha
Cc: Woojung Huh
--
The KSZ driver uses one regmap per register width (8/16/32), each with
it's own lock, but accessing the same set of registers. In theory, it
is possible to create a race condition between these regmaps, although
the underlying bus (SPI or I2C) locking should assure nothing bad will
really happen an
On 10/11/2019 9:03 PM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> NET_VENDOR_BROADCOM is intended to control a kconfig menu only.
> It should not have anything to do with code generation.
> As such, it should not select DIMLIB for all drivers under
> NET_VENDOR_BROADCOM. Instead each driver
On Thu, Oct 10, 2019 at 12:07 PM Guillaume Nault wrote:
>
> In rtnl_net_notifyid(), we certainly can't pass a null GFP flag to
> rtnl_notify(). A GFP_KERNEL flag would be fine in most circumstances,
> but there are a few paths calling rtnl_net_notifyid() from atomic
> context or from RCU critical
From: Soheil Hassas Yeganeh
Date: Thu, 10 Oct 2019 23:27:02 -0400
> From: Soheil Hassas Yeganeh
>
> tcp_zerocopy_receive() rounds down the zc->length a multiple of
> PAGE_SIZE. This results in two issues:
> - tcp_zerocopy_receive sets recv_skip_hint to the length of the
> receive queue if the
Please respin with a proper cover letter and appropriate Fixes:
tag(s).
Thank you.
From: Guillaume Nault
Date: Thu, 10 Oct 2019 21:07:29 +0200
> Before I spend more time on this, do we have a chance to make
> ovs_vport_cmd_fill_info() and __dev_notify_flags() sleepable?
> I'd like to avoid passing GFP flags along these call chains, if at all
> possible.
OVS folks, please weigh
From: Eric Dumazet
Date: Thu, 10 Oct 2019 20:17:37 -0700
> This all started with a KCSAN report (included
> in "tcp: annotate tp->rcv_nxt lockless reads" changelog)
>
> tcp_poll() runs in a lockless way. This means that about
> all accesses of tcp socket fields done in tcp_poll() context
> need
From: Marek Vasut
Date: Sun, 13 Oct 2019 12:50:15 +0200
> On 10/13/19 2:21 AM, David Miller wrote:
>> From: David Miller
>> Date: Sat, 12 Oct 2019 17:20:55 -0700 (PDT)
>>
>>> From: Marek Vasut
>>> Date: Thu, 10 Oct 2019 20:25:08 +0200
>>>
The KSZ driver uses one regmap per register width
On 10/12/19 11:22 PM, Heiner Kallweit wrote:
[...]
>>> @@ -1141,13 +1174,12 @@ static struct phy_driver ksphy_driver[] = {
>>> .suspend= genphy_suspend,
>>> .resume = genphy_resume,
>>> }, {
>>> - .phy_id = PHY_ID_KSZ8795,
>>> - .phy_id_mask= MICREL_PHY_ID
On 10/13/19 2:21 AM, David Miller wrote:
> From: David Miller
> Date: Sat, 12 Oct 2019 17:20:55 -0700 (PDT)
>
>> From: Marek Vasut
>> Date: Thu, 10 Oct 2019 20:25:08 +0200
>>
>>> The KSZ driver uses one regmap per register width (8/16/32), each with
>>> it's own lock, but accessing the same set
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/xiangxia-m-yue-gmail-com/optimize-openvswitch-flow-looking-up/20191013-161404
reproduce:
# apt-get install sparse
# sparse
Hi,all
1. according to my test, bandwidth limitation is inaccurate for
ingress ipv6 . The accuracy is affected by burst. if rate is less
than 100mbit , set burst to 1MB or 2MB, the result is almost
acceptable. but when rate is bigger , the result is approximately 1/3
of rate.
command: tc fi
33 matches
Mail list logo
