* [PATCH net-next] bpf: make bpf_xdp_adjust_head support mandatory
From: Daniel Borkmann @ 2017-04-24 20:14 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
Now that also the last in-tree user of the xdp_adjust_head bit has
been removed, we can remove the flag from struct bpf_prog altogether.
This, at the same time, also makes sure that any future driver for
XDP comes with bpf_xdp_adjust_head() support right away.
A rejection based on this flag would also mean that tail calls
couldn't be used with such driver as per c2002f983767 ("bpf: fix
checking xdp_adjust_head on tail calls") fix, thus lets not allow
for it in the first place.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/linux/filter.h | 3 +--
kernel/bpf/verifier.c | 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 511fe91..9a7786d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -413,8 +413,7 @@ struct bpf_prog {
locked:1, /* Program image locked? */
gpl_compatible:1, /* Is filter GPL compatible? */
cb_access:1, /* Is control block accessed? */
- dst_needed:1, /* Do we need dst entry? */
- xdp_adjust_head:1; /* Adjusting pkt head? */
+ dst_needed:1; /* Do we need dst entry? */
kmemcheck_bitfield_end(meta);
enum bpf_prog_type type; /* Type of BPF program */
u32 len; /* Number of filter blocks */
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index ca15cf2..6f8b6ed 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3346,8 +3346,6 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
prog->dst_needed = 1;
if (insn->imm == BPF_FUNC_get_prandom_u32)
bpf_user_rnd_init_once();
- if (insn->imm == BPF_FUNC_xdp_adjust_head)
- prog->xdp_adjust_head = 1;
if (insn->imm == BPF_FUNC_tail_call) {
/* If we tail call into other programs, we
* cannot make any assumptions since they can
@@ -3355,7 +3353,6 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
* the program array.
*/
prog->cb_access = 1;
- prog->xdp_adjust_head = 1;
/* mark bpf_tail_call as different opcode to avoid
* conditional branch in the interpeter for every normal
--
1.9.3
^ permalink raw reply related
* EXTREMELY IMPORTANT
From: Ms. Katherine @ 2017-04-24 18:59 UTC (permalink / raw)
To: Recipients
Dear Beloved, Sorry for the inconvenience, I am getting in touch with you regarding an extremely important and urgent matter, Please I need your urgent assistance and idea to finish up a project (Orphanage Home) Due to my health condition, Everything is available to finish up the project, All I need is your idea and trust.
Sehr geehrte Geliebte, traurig für die Unannehmlichkeiten, ich bin in Kontakt mit Ihnen über eine äußerst wichtige und dringende Angelegenheit, Bitte brauche ich Ihre dringende Hilfe und Idee, um ein Projekt zu beenden (Orphanage Home) Wegen meines Gesundheitszustandes ist alles verfügbar Beenden Sie das Projekt, Alles was ich brauche ist Ihre Idee und Vertrauen.
Please contact me for more details.
Contact Email: kathrynnmison@gmail.com
Thanks
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH net-next] bpf: make bpf_xdp_adjust_head support mandatory
From: David Miller @ 2017-04-24 20:18 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <6e25ef44c5de02d1feb8b4cc8a2cf60adb4a596e.1493064530.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 24 Apr 2017 22:14:35 +0200
> Now that also the last in-tree user of the xdp_adjust_head bit has
> been removed, we can remove the flag from struct bpf_prog altogether.
>
> This, at the same time, also makes sure that any future driver for
> XDP comes with bpf_xdp_adjust_head() support right away.
>
> A rejection based on this flag would also mean that tail calls
> couldn't be used with such driver as per c2002f983767 ("bpf: fix
> checking xdp_adjust_head on tail calls") fix, thus lets not allow
> for it in the first place.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks Daniel.
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Lars Erik Storbukås @ 2017-04-24 20:20 UTC (permalink / raw)
To: Neal Cardwell; +Cc: LKML, Netdev
In-Reply-To: <CADVnQyk9-OGKBKBvQ76itP5JwbVBPt40S8KJ+6oY506hVpMEYA@mail.gmail.com>
2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
> <storbukas.dev@gmail.com> wrote:
>> I'm trying to get amount of congestion events in TCP caused by
>> DUPACK's (fast retransmissions), and can't seem to find any variable
>> in the TCP info struct which hold that value. There are three
>> variables in the TCP info struct that seem to hold similar congestion
>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>> tcpi_total_retrans;
>>
>> Does anyone have any pointers on how to find this value in the TCP code?
>>
>> Please CC me personally if answering this question. Any help is
>> greatly appreciated.
>
> [I'm cc-ing the netdev list.]
>
> Do you need this per-socket? On a per-socket basis, I do not think
> there are separate totals for fast retransmits and timeout
> retransmits.
>
> If a global number is good enough, then you can get that number from
> the global network statistics. In "nstat" output they look like:
>
> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>
> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>
> It sounds like TcpExtTCPFastRetrans is what you are after.
>
> Hope that helps,
> neal
Thanks for your answer Neal.
Yes, I need this information per-socket. What would be the most
appropriate place to update this value?
If none of the variables (mentioned above) contain any value in
regards to fast retransmits, what does the different values represent?
/Lars Erik
^ permalink raw reply
* Re: [PATCH net-next 0/3] Misc BPF cleanup
From: David Miller @ 2017-04-24 20:20 UTC (permalink / raw)
To: alexander; +Cc: netdev, daniel, ast
In-Reply-To: <20170424133108.31595-1-alexander@alemayhu.com>
From: Alexander Alemayhu <alexander@alemayhu.com>
Date: Mon, 24 Apr 2017 15:31:05 +0200
> while looking into making the Makefile in samples/bpf better handle O= I saw
> several warnings when running `make clean && make samples/bpf/`. This series
> reduces those warnings.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: David Miller @ 2017-04-24 20:30 UTC (permalink / raw)
To: jhs; +Cc: simon.horman, jiri, xiyou.wangcong, eric.dumazet, netdev, tom,
pablo
In-Reply-To: <2ca4266f-a164-d2ad-37fa-45f7ae354eb8@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 24 Apr 2017 08:49:00 -0400
> Yes, space is important and if i can express upto 32 flags
> with one TLV rather than 32 TLVs i choose one TLV.
Which is fine. But two things:
1) Again, bits you aren't using now, make sure userspace doesn't
set them. And if it does, reject.
2) If you are worried about performance, we're talking about a TLV in
the request here not the dump response itself so performance isn't
a real issue as Pablo mentioned.
^ permalink raw reply
* [PATCH] net: ethernet: ti: netcp_core: remove unused compl queue mapping
From: Ivan Khoronzhuk @ 2017-04-24 20:54 UTC (permalink / raw)
To: netdev, w-kwok2, m-karicheri2
Cc: linux-kernel, grygorii.strashko, Ivan Khoronzhuk
This code is unused and probably was unintentionally left while
moving completion queue mapping in submit function.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on net-next/master
drivers/net/ethernet/ti/netcp_core.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 9027c9c..729a7da 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1134,7 +1134,6 @@ netcp_tx_map_skb(struct sk_buff *skb, struct netcp_intf *netcp)
u32 buf_len = skb_frag_size(frag);
dma_addr_t desc_dma;
u32 desc_dma_32;
- u32 pkt_info;
dma_addr = dma_map_page(dev, page, page_offset, buf_len,
DMA_TO_DEVICE);
@@ -1151,9 +1150,6 @@ netcp_tx_map_skb(struct sk_buff *skb, struct netcp_intf *netcp)
}
desc_dma = knav_pool_desc_virt_to_dma(netcp->tx_pool, ndesc);
- pkt_info =
- (netcp->tx_compl_qid & KNAV_DMA_DESC_RETQ_MASK) <<
- KNAV_DMA_DESC_RETQ_SHIFT;
set_pkt_info(dma_addr, buf_len, 0, ndesc);
desc_dma_32 = (u32)desc_dma;
set_words(&desc_dma_32, 1, &pdesc->next_desc);
--
2.7.4
^ permalink raw reply related
* Re: Get amount of fast retransmissions from TCP info
From: Neal Cardwell @ 2017-04-24 21:00 UTC (permalink / raw)
To: Lars Erik Storbukås; +Cc: LKML, Netdev
In-Reply-To: <CAF0XkCDTexCTxPmGvM4+FZtVhQg13Ggsbm0QSbcKCSR5LGbs9w@mail.gmail.com>
"
On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås
<storbukas.dev@gmail.com> wrote:
> 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
>> <storbukas.dev@gmail.com> wrote:
>>> I'm trying to get amount of congestion events in TCP caused by
>>> DUPACK's (fast retransmissions), and can't seem to find any variable
>>> in the TCP info struct which hold that value. There are three
>>> variables in the TCP info struct that seem to hold similar congestion
>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>>> tcpi_total_retrans;
>>>
>>> Does anyone have any pointers on how to find this value in the TCP code?
>>>
>>> Please CC me personally if answering this question. Any help is
>>> greatly appreciated.
>>
>> [I'm cc-ing the netdev list.]
>>
>> Do you need this per-socket? On a per-socket basis, I do not think
>> there are separate totals for fast retransmits and timeout
>> retransmits.
>>
>> If a global number is good enough, then you can get that number from
>> the global network statistics. In "nstat" output they look like:
>>
>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>>
>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>>
>> It sounds like TcpExtTCPFastRetrans is what you are after.
>>
>> Hope that helps,
>> neal
>
> Thanks for your answer Neal.
>
> Yes, I need this information per-socket. What would be the most
> appropriate place to update this value?
Is this for a custom kernel you are building? Or are you proposing
this for upstream?
IMHO the best place to add this for your custom kernel would be in
_tcp_retransmit_skb() around the spot with the comment "Update global
and local TCP statistics". Something like:
/* Update global and local TCP statistics. */
...
tp->total_retrans += segs;
if (icsk->icsk_ca_state == TCP_CA_Loss)
tp->slow_retrans += segs;
else
tp->fast_retrans += segs;
> If none of the variables (mentioned above) contain any value in
> regards to fast retransmits, what does the different values represent?
tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet
tcpi_retrans: retransmitted packets estimated to be in-flight in the network now
tcpi_total_retrans: total number of retransmitted packets over the
life of the connection
Can you sketch out why you need to have separate counts for fast
retransmits and timeout/slow-start retransmits?
neal
^ permalink raw reply
* Re: [PATCH v3 net] net: ipv6: regenerate host route if moved to gc list
From: Martin KaFai Lau @ 2017-04-24 21:08 UTC (permalink / raw)
To: David Ahern; +Cc: Eric Dumazet, netdev, dvyukov, andreyknvl, mmanning
In-Reply-To: <0ebdefd9-3f89-1876-ba03-1a8277ff79e2@cumulusnetworks.com>
On Mon, Apr 24, 2017 at 01:37:00PM -0600, David Ahern wrote:
> On 4/24/17 10:39 AM, Eric Dumazet wrote:
> >
> > Very nice changelog !
>
>
> Thanks. Given my aggressive brain cell recycling program, I needed to
> write down the analysis.
>
>
>
> >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> >> index 80ce478c4851..93f81d9cd85f 100644
> >> --- a/net/ipv6/addrconf.c
> >> +++ b/net/ipv6/addrconf.c
> >> @@ -3271,14 +3271,25 @@ static void addrconf_gre_config(struct net_device *dev)
> >> static int fixup_permanent_addr(struct inet6_dev *idev,
> >> struct inet6_ifaddr *ifp)
> >> {
> >> - if (!ifp->rt) {
> >> - struct rt6_info *rt;
> >> + /* rt6i_ref == 0 means the host route was removed from the
> >> + * FIB, for example, if 'lo' device is taken down. In that
> >> + * case regenerate the host route.
> >> + */
> >> + if (!ifp->rt || !atomic_read(&ifp->rt->rt6i_ref)) {
> >> + struct rt6_info *rt, *prev;
> >>
> >> rt = addrconf_dst_alloc(idev, &ifp->addr, false);
> >> if (unlikely(IS_ERR(rt)))
> >> return PTR_ERR(rt);
> >>
> >> + prev = ifp->rt;
> >
> > I would feel more comfortable if this was moved after the spin_lock() ?
>
> That's what I had in v2; it reads better to me even if it is not
> technically required (all changes to ifp->rt happen under rtnl).
>
> Martin you agree?
Agree.
My question was mainly on the added spin_lock.
>
> I'll send a v3 tomorrow -- allow more time for other comments.
^ permalink raw reply
* [PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
Hi David,
This patch series contains fixes for the 58xx devices (Broadcom Northstar
Plus), which were identified thanks to the help of Eric Anholt.
Florian Fainelli (3):
net: dsa: b53: Include IMP/CPU port in dumb forwarding mode
net: dsa: b53: Implement software reset for 58xx devices
net: dsa: b53: Fix CPU port for 58xx devices
drivers/net/dsa/b53/b53_common.c | 37 +++++++++++++++++++++++++++++++++++--
drivers/net/dsa/b53/b53_regs.h | 5 +++++
2 files changed, 40 insertions(+), 2 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH net 1/3] net: dsa: b53: Include IMP/CPU port in dumb forwarding mode
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
Since Broadcom tags are not enabled in b53 (DSA_PROTO_TAG_NONE), we need
to make sure that the IMP/CPU port is included in the forwarding
decision.
Without this change, switching between non-management ports would work,
but not between management ports and non-management ports thus breaking
the default state in which DSA switch are brought up.
Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 10 ++++++++++
drivers/net/dsa/b53/b53_regs.h | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 8cf4801994e8..ca7f3b005a29 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -326,6 +326,7 @@ static void b53_get_vlan_entry(struct b53_device *dev, u16 vid,
static void b53_set_forwarding(struct b53_device *dev, int enable)
{
+ struct dsa_switch *ds = dev->ds;
u8 mgmt;
b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
@@ -336,6 +337,15 @@ static void b53_set_forwarding(struct b53_device *dev, int enable)
mgmt &= ~SM_SW_FWD_EN;
b53_write8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, mgmt);
+
+ /* Include IMP port in dumb forwarding mode when no tagging protocol is
+ * set
+ */
+ if (ds->ops->get_tag_protocol(ds) == DSA_TAG_PROTO_NONE) {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_CTRL, &mgmt);
+ mgmt |= B53_MII_DUMB_FWDG_EN;
+ b53_write8(dev, B53_CTRL_PAGE, B53_SWITCH_CTRL, mgmt);
+ }
}
static void b53_enable_vlan(struct b53_device *dev, bool enable)
diff --git a/drivers/net/dsa/b53/b53_regs.h b/drivers/net/dsa/b53/b53_regs.h
index 9fd24c418fa4..f2a060e7a637 100644
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -104,6 +104,10 @@
#define B53_UC_FWD_EN BIT(6)
#define B53_MC_FWD_EN BIT(7)
+/* Switch control (8 bit) */
+#define B53_SWITCH_CTRL 0x22
+#define B53_MII_DUMB_FWDG_EN BIT(6)
+
/* (16 bit) */
#define B53_UC_FLOOD_MASK 0x32
#define B53_MC_FLOOD_MASK 0x34
--
2.9.3
^ permalink raw reply related
* [PATCH net 3/3] net: dsa: b53: Fix CPU port for 58xx devices
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
The 58xx devices (Northstar Plus) do actually have their CPU port wired
at port 8, it was unfortunately set to port 5 (B53_CPU_PORT_25) which is
incorrect, since that is the second possible management port.
Fixes: 991a36bb4645 ("net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated switch")
Reported-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index b66ee18cbe49..fa0eece21eef 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1764,7 +1764,7 @@ static const struct b53_chip_data b53_switch_chips[] = {
.vlans = 4096,
.enabled_ports = 0x1ff,
.arl_entries = 4,
- .cpu_port = B53_CPU_PORT_25,
+ .cpu_port = B53_CPU_PORT,
.vta_regs = B53_VTA_REGS,
.duplex_reg = B53_DUPLEX_STAT_GE,
.jumbo_pm_reg = B53_JUMBO_PORT_MASK,
--
2.9.3
^ permalink raw reply related
* [PATCH net 2/3] net: dsa: b53: Implement software reset for 58xx devices
From: Florian Fainelli @ 2017-04-24 21:27 UTC (permalink / raw)
To: netdev; +Cc: andrew, vivien.didelot, eric, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
Implement the correct software reset sequence for 58xx devices by
setting all 3 reset bits and polling for the SW_RST bit to clear itself
without a given timeout. We cannot use is58xx() here because that would
also include the 7445/7278 Starfighter 2 which have their own driver
doing the reset earlier on due to the HW specific integration.
Fixes: 991a36bb4645 ("net: dsa: b53: Add support for BCM585xx/586xx/88312 integrated switch")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 25 ++++++++++++++++++++++++-
drivers/net/dsa/b53/b53_regs.h | 1 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index ca7f3b005a29..b66ee18cbe49 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -608,7 +608,8 @@ static void b53_switch_reset_gpio(struct b53_device *dev)
static int b53_switch_reset(struct b53_device *dev)
{
- u8 mgmt;
+ unsigned int timeout = 1000;
+ u8 mgmt, reg;
b53_switch_reset_gpio(dev);
@@ -617,6 +618,28 @@ static int b53_switch_reset(struct b53_device *dev)
b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, 0x00);
}
+ /* This is specific to 58xx devices here, do not use is58xx() which
+ * covers the larger Starfigther 2 family, including 7445/7278 which
+ * still use this driver as a library and need to perform the reset
+ * earlier.
+ */
+ if (dev->chip_id == BCM58XX_DEVICE_ID) {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SOFTRESET, ®);
+ reg |= SW_RST | EN_SW_RST | EN_CH_RST;
+ b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, reg);
+
+ do {
+ b53_read8(dev, B53_CTRL_PAGE, B53_SOFTRESET, ®);
+ if (!(reg & SW_RST))
+ break;
+
+ usleep_range(1000, 2000);
+ } while (timeout-- > 0);
+
+ if (timeout == 0)
+ return -ETIMEDOUT;
+ }
+
b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
if (!(mgmt & SM_SW_FWD_EN)) {
diff --git a/drivers/net/dsa/b53/b53_regs.h b/drivers/net/dsa/b53/b53_regs.h
index f2a060e7a637..e5c86d44667a 100644
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -143,6 +143,7 @@
/* Software reset register (8 bit) */
#define B53_SOFTRESET 0x79
#define SW_RST BIT(7)
+#define EN_CH_RST BIT(6)
#define EN_SW_RST BIT(4)
/* Fast Aging Control register (8 bit) */
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] stmmac: Add support for SIMATIC IOT2000 platform
From: Andy Shevchenko @ 2017-04-24 21:27 UTC (permalink / raw)
To: Jan Kiszka
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev,
Linux Kernel Mailing List, Sascha Weisenberger
In-Reply-To: <8c536123-6189-e0b6-1977-dc7a521718dd@siemens.com>
On Mon, Apr 24, 2017 at 10:27 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> The IOT2000 is industrial controller platform, derived from the Intel
> Galileo Gen2 board. The variant IOT2020 comes with one LAN port, the
> IOT2040 has two of them. They can be told apart based on the board asset
> tag in the DMI table.
>
> Based on patch by Sascha Weisenberger.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
Shoudn't be ordered other way around?
> + const char *asset_tag;
I guess this is redundant. See below.
> + {
> + .name = "SIMATIC IOT2000",
> + .asset_tag = "6ES7647-0AA00-0YA2",
> + .func = 6,
> + .phy_addr = 1,
> + },
The below has same definition disregard on asset_tag.
> + {
> + .name = "SIMATIC IOT2000",
> + .asset_tag = "6ES7647-0AA00-1YA2",
> + .func = 6,
> + .phy_addr = 1,
> + },
> + {
> + .name = "SIMATIC IOT2000",
> + .asset_tag = "6ES7647-0AA00-1YA2",
> + .func = 7,
> + .phy_addr = 1,
> + },
How this supposed to work if phy_addr is the same?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Lars Erik Storbukås @ 2017-04-24 21:31 UTC (permalink / raw)
To: Neal Cardwell; +Cc: LKML, Netdev
In-Reply-To: <CADVnQyn=6wYbVP0m3mepGU23LcEn_BK_TKoSNxVf=TUz9Q+f8g@mail.gmail.com>
2017-04-24 23:00 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
> On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås
> <storbukas.dev@gmail.com> wrote:
>> 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
>>> <storbukas.dev@gmail.com> wrote:
>>>> I'm trying to get amount of congestion events in TCP caused by
>>>> DUPACK's (fast retransmissions), and can't seem to find any variable
>>>> in the TCP info struct which hold that value. There are three
>>>> variables in the TCP info struct that seem to hold similar congestion
>>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>>>> tcpi_total_retrans;
>>>>
>>>> Does anyone have any pointers on how to find this value in the TCP code?
>>>>
>>>> Please CC me personally if answering this question. Any help is
>>>> greatly appreciated.
>>>
>>> [I'm cc-ing the netdev list.]
>>>
>>> Do you need this per-socket? On a per-socket basis, I do not think
>>> there are separate totals for fast retransmits and timeout
>>> retransmits.
>>>
>>> If a global number is good enough, then you can get that number from
>>> the global network statistics. In "nstat" output they look like:
>>>
>>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>>>
>>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>>>
>>> It sounds like TcpExtTCPFastRetrans is what you are after.
>>>
>>> Hope that helps,
>>> neal
>>
>> Thanks for your answer Neal.
>>
>> Yes, I need this information per-socket. What would be the most
>> appropriate place to update this value?
>
> Is this for a custom kernel you are building? Or are you proposing
> this for upstream?
This is currently for a custom kernel.
> IMHO the best place to add this for your custom kernel would be in
> _tcp_retransmit_skb() around the spot with the comment "Update global
> and local TCP statistics". Something like:
>
> /* Update global and local TCP statistics. */
> ...
> tp->total_retrans += segs;
> if (icsk->icsk_ca_state == TCP_CA_Loss)
> tp->slow_retrans += segs;
> else
> tp->fast_retrans += segs;
>
Excellent. That seems like a logical place.
>> If none of the variables (mentioned above) contain any value in
>> regards to fast retransmits, what does the different values represent?
>
> tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet
>
> tcpi_retrans: retransmitted packets estimated to be in-flight in the network now
>
> tcpi_total_retrans: total number of retransmitted packets over the
> life of the connection
>
> Can you sketch out why you need to have separate counts for fast
> retransmits and timeout/slow-start retransmits?
>
> neal
I'm working on the implementation of a Deadline Aware, Less than Best
Effort framework proposed by David A. Hayes, David Ros, Andreas
Petlund. A framework for adding both LBE behaviour and awareness of
“soft” delivery deadlines to any congestion control (CC) algorithm,
whether loss-based, delay- based or explicit signaling-based. This
effectively allows it to turn an arbitrary CC protocol into a
scavenger protocol that dynamically adapts its sending rate to network
conditions and remaining time before the deadline, to balance
timeliness and transmission aggressiveness.
/Lars Erik
^ permalink raw reply
* Re: [PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes
From: Eric Anholt @ 2017-04-24 21:32 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: andrew, vivien.didelot, jon.mason, Florian Fainelli
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
Florian Fainelli <f.fainelli@gmail.com> writes:
> Hi David,
>
> This patch series contains fixes for the 58xx devices (Broadcom Northstar
> Plus), which were identified thanks to the help of Eric Anholt.
This series is:
Tested-by: Eric Anholt <eric@anholt.net>
Thanks for all your help debugging this, Florian! I'll send out my DT
changes now.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-04-24 21:50 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn, netdev,
Rob Herring, Mark Rutland, devicetree
Cc: Scott Branden, Jon Mason, Ray Jui, linux-kernel, Eric Anholt,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <20170424215022.30382-1-eric@anholt.net>
Cygnus is a small family of SoCs, of which we currently have
devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
same as 58xx, just requiring a tiny bit of setup that was previously
missing.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
drivers/net/dsa/b53/b53_srab.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
index d6c6e41648d4..49c93d3c0839 100644
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -29,6 +29,9 @@ Required properties:
"brcm,bcm58625-srab"
"brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
+ For the BCM11360 SoC, must be:
+ "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
+
For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
"brcm,bcm3384-switch"
"brcm,bcm6328-switch"
diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
index 8a62b6a69703..c37ffd1b6833 100644
--- a/drivers/net/dsa/b53/b53_srab.c
+++ b/drivers/net/dsa/b53/b53_srab.c
@@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm53018-srab" },
{ .compatible = "brcm,bcm53019-srab" },
{ .compatible = "brcm,bcm5301x-srab" },
+ { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
@@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
+ { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ /* sentinel */ },
};
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] net: dsa: b53: BCM11360 support
From: Eric Anholt @ 2017-04-24 21:50 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn, netdev,
Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason, Eric Anholt
This little patch series follows on from Florian's fixes that he just
sent, and enables the ethernet on the 911360_EP board.
Without Florian's fixes, the controller comes up and forwarding
happens between eth1 and eth2, but the CPU's eth0 packets don't get
forwarded.
Eric Anholt (2):
net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
Documentation/devicetree/bindings/net/dsa/b53.txt | 3 ++
arch/arm/boot/dts/bcm-cygnus.dtsi | 60 +++++++++++++++++++++++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++
drivers/net/dsa/b53/b53_srab.c | 2 +
4 files changed, 73 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-24 21:50 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn, netdev,
Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason, Eric Anholt
In-Reply-To: <20170424215022.30382-1-eric@anholt.net>
Cygnus has a single amac controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
2 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..318899df9972 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -142,6 +142,56 @@
interrupts = <0>;
};
+ mdio: mdio@18002000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18002000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+
+ gphy0: eth-gphy@0 {
+ reg = <0>;
+ max-speed = <1000>;
+ };
+
+ gphy1: eth-gphy@1 {
+ reg = <1>;
+ max-speed = <1000>;
+ };
+ };
+
+ dsa: dsa@18007000 {
+ compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
+ reg = <0x18007000 0x1000>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port0@0 {
+ reg = <0>;
+ phy-handle = <&gphy0>;
+ phy-mode = "rgmii";
+ };
+
+ port1@1 {
+ reg = <1>;
+ phy-handle = <&gphy1>;
+ phy-mode = "rgmii";
+ };
+
+ port8@8 {
+ reg = <8>;
+ label = "cpu";
+ ethernet = <ð0>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+
i2c0: i2c@18008000 {
compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
reg = <0x18008000 0x100>;
@@ -295,6 +345,16 @@
status = "disabled";
};
+ eth0: enet@18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x18110000 0x1000>;
+ reg-names = "amac_base", "idm_base";
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1000>;
+ status = "disabled";
+ };
+
nand: nand@18046000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x18046000 0x600>, <0xf8105408 0x600>,
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
index 8b3800f46288..2a1f54ab3574 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -57,6 +57,14 @@
};
};
+&dsa {
+ status = "okay";
+};
+
+ð0 {
+ status = "okay";
+};
+
&uart3 {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Florian Fainelli @ 2017-04-24 21:51 UTC (permalink / raw)
To: Eric Anholt, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-2-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
On 04/24/2017 02:50 PM, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Florian Fainelli @ 2017-04-24 21:54 UTC (permalink / raw)
To: Eric Anholt, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-3-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
On 04/24/2017 02:50 PM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
This looks fine, just a few nits on the label names:
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -142,6 +142,56 @@
> interrupts = <0>;
> };
>
> + mdio: mdio@18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + gphy0: eth-gphy@0 {
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +
> + gphy1: eth-gphy@1 {
> + reg = <1>;
> + max-speed = <1000>;
> + };
> + };
> +
> + dsa: dsa@18007000 {
This would be better named switch: switch@18007000
> + compatible = "brcm,bcm11360-srab", "brcm,cygnus-srab";
> + reg = <0x18007000 0x1000>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port0@0 {
You can probably just put port@0
> + reg = <0>;
> + phy-handle = <&gphy0>;
> + phy-mode = "rgmii";
> + };
> +
> + port1@1 {
And so on
> + reg = <1>;
> + phy-handle = <&gphy1>;
> + phy-mode = "rgmii";
> + };
> +
> + port8@8 {
And so forth
> + reg = <8>;
> + label = "cpu";
> + ethernet = <ð0>;
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +
> i2c0: i2c@18008000 {
> compatible = "brcm,cygnus-iproc-i2c", "brcm,iproc-i2c";
> reg = <0x18008000 0x100>;
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet@18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
> + status = "disabled";
> + };
> +
> nand: nand@18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
> diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
> index 8b3800f46288..2a1f54ab3574 100644
> --- a/arch/arm/boot/dts/bcm911360_entphn.dts
> +++ b/arch/arm/boot/dts/bcm911360_entphn.dts
> @@ -57,6 +57,14 @@
> };
> };
>
> +&dsa {
> + status = "okay";
> +};
And that would be &switch here then.
With that fixed:
Reviewed-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> +
> +ð0 {
> + status = "okay";
> +};
> +
> &uart3 {
> status = "okay";
> };
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Andrew Lunn @ 2017-04-24 22:08 UTC (permalink / raw)
To: Eric Anholt
Cc: Florian Fainelli, Vivien Didelot, netdev-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-3-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> + mdio: mdio@18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + gphy0: eth-gphy@0 {
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +
> + gphy1: eth-gphy@1 {
> + reg = <1>;
> + max-speed = <1000>;
> + };
> + };
Hi Eric
Do these max-speed properties do anything useful? Is the PHY capable
of > 1Gbps?
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-04-24 22:18 UTC (permalink / raw)
To: David Miller
Cc: simon.horman, jiri, xiyou.wangcong, eric.dumazet, netdev, tom,
pablo
In-Reply-To: <20170424.163033.797679814568299306.davem@davemloft.net>
On 17-04-24 04:30 PM, David Miller wrote:
> Which is fine. But two things:
>
> 1) Again, bits you aren't using now, make sure userspace doesn't
> set them. And if it does, reject.
>
I meet those goals on the bit checks but i went a slightly different
path with a patch I posted[1]
With the posted patch: unknow bits set will result in a kernel rejection
unless the user space explicitly ask the kernel to ignore flags it
doesnt understand and just handles what it knows. This reduces the
amount of work in tc.
If this ok I will resend tomorrow.
> 2) If you are worried about performance, we're talking about a TLV in
> the request here not the dump response itself so performance isn't
> a real issue as Pablo mentioned.
doesnt make much of a difference for a simple request, true; i was more
worried about how we pack similar things for dumps or for large
set requests in general. And note it makes no difference if i make the
bitmask u32 or u16 - the TLV still eats 32 + 32 bits. So using a u32
is sensible.
cheers,
jamal
[1]
This is because i worry about making large changes to
the behavior of user space apps like tc. If I reject I will need to
change tc to detect this rejection and retry (and I dont think
extended ACKs in their current shape are ready to provide any
meaningful detail).
^ permalink raw reply
* Re: Get amount of fast retransmissions from TCP info
From: Andreas Petlund @ 2017-04-24 22:20 UTC (permalink / raw)
To: Neal Cardwell; +Cc: LKML, Netdev, Lars Erik Storbukås
In-Reply-To: <CAF0XkCAZJd7adZf6VHdDc2yesyKQ8DqQnDOv_uk8o8mOVGMRyA@mail.gmail.com>
> On 24 Apr 2017, at 23:31, Lars Erik Storbukås <storbukas.dev@gmail.com> wrote:
>
> 2017-04-24 23:00 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>> On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås
>> <storbukas.dev@gmail.com> wrote:
>>> 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardwell@google.com>:
>>>> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås
>>>> <storbukas.dev@gmail.com> wrote:
>>>>> I'm trying to get amount of congestion events in TCP caused by
>>>>> DUPACK's (fast retransmissions), and can't seem to find any variable
>>>>> in the TCP info struct which hold that value. There are three
>>>>> variables in the TCP info struct that seem to hold similar congestion
>>>>> values: __u8 tcpi_retransmits;__u32 tcpi_retrans; __u32
>>>>> tcpi_total_retrans;
>>>>>
>>>>> Does anyone have any pointers on how to find this value in the TCP code?
>>>>>
>>>>> Please CC me personally if answering this question. Any help is
>>>>> greatly appreciated.
>>>>
>>>> [I'm cc-ing the netdev list.]
>>>>
>>>> Do you need this per-socket? On a per-socket basis, I do not think
>>>> there are separate totals for fast retransmits and timeout
>>>> retransmits.
>>>>
>>>> If a global number is good enough, then you can get that number from
>>>> the global network statistics. In "nstat" output they look like:
>>>>
>>>> TcpExtTCPFastRetrans = packets sent in fast retransmit / fast recovery
>>>>
>>>> TcpExtTCPSlowStartRetrans = packets sent in timeout recovery
>>>>
>>>> It sounds like TcpExtTCPFastRetrans is what you are after.
>>>>
>>>> Hope that helps,
>>>> neal
>>>
>>> Thanks for your answer Neal.
>>>
>>> Yes, I need this information per-socket. What would be the most
>>> appropriate place to update this value?
>>
>> Is this for a custom kernel you are building? Or are you proposing
>> this for upstream?
>
> This is currently for a custom kernel.
>
>> IMHO the best place to add this for your custom kernel would be in
>> _tcp_retransmit_skb() around the spot with the comment "Update global
>> and local TCP statistics". Something like:
>>
>> /* Update global and local TCP statistics. */
>> ...
>> tp->total_retrans += segs;
>> if (icsk->icsk_ca_state == TCP_CA_Loss)
>> tp->slow_retrans += segs;
>> else
>> tp->fast_retrans += segs;
>>
>
> Excellent. That seems like a logical place.
>
>>> If none of the variables (mentioned above) contain any value in
>>> regards to fast retransmits, what does the different values represent?
>>
>> tcpi_retransmits: consecutive retransmits of lowest-sequence outstanding packet
>>
>> tcpi_retrans: retransmitted packets estimated to be in-flight in the network now
>>
>> tcpi_total_retrans: total number of retransmitted packets over the
>> life of the connection
>>
>> Can you sketch out why you need to have separate counts for fast
>> retransmits and timeout/slow-start retransmits?
>>
>> neal
>
> I'm working on the implementation of a Deadline Aware, Less than Best
> Effort framework proposed by David A. Hayes, David Ros, Andreas
> Petlund. A framework for adding both LBE behaviour and awareness of
> “soft” delivery deadlines to any congestion control (CC) algorithm,
> whether loss-based, delay- based or explicit signaling-based. This
> effectively allows it to turn an arbitrary CC protocol into a
> scavenger protocol that dynamically adapts its sending rate to network
> conditions and remaining time before the deadline, to balance
> timeliness and transmission aggressiveness.
>
Just for the record, the paper is not publicly available yet, so it’s a bit hard to find:)
It will be published in IFIP Networking in June.
We will make it available as soon as the conference regulations allows.
You can find the abstract here:
https://www.simula.no/publications/framework-less-best-effort-congestion-control-soft-deadlines
Cheers,
Andreas Petlund
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: David Miller @ 2017-04-24 22:24 UTC (permalink / raw)
To: jhs; +Cc: simon.horman, jiri, xiyou.wangcong, eric.dumazet, netdev, tom,
pablo
In-Reply-To: <ebfe9e52-f130-3733-9348-aac022a18748@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 24 Apr 2017 18:18:42 -0400
> With the posted patch: unknow bits set will result in a kernel
> rejection unless the user space explicitly ask the kernel to ignore
> flags it doesnt understand and just handles what it knows. This
> reduces the amount of work in tc.
...
> [1]
> This is because i worry about making large changes to
> the behavior of user space apps like tc. If I reject I will need to
> change tc to detect this rejection and retry (and I dont think
> extended ACKs in their current shape are ready to provide any
> meaningful detail).
I think we should eat the pain now and use the strict checks
for all new features like this.
I'm sorry if this makes more work for you, but this is really
how we have to proceed moving forward.
Thanks.
^ 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