* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Florian Fainelli @ 2017-04-24 23:17 UTC (permalink / raw)
To: Arun Parameswaran, 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: <1361654c-e4eb-e0a0-3397-b43235b5ff60-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 04/24/2017 04:15 PM, Arun Parameswaran wrote:
>
>
> On 17-04-24 04:07 PM, Florian Fainelli wrote:
>> On 04/24/2017 04:03 PM, Arun Parameswaran wrote:
>>> Hi Eric
>>>
>>> A comment on the Device ID.
>>>
>>>
>>> On 17-04-24 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>
>>>> ---
>>>> 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 },
>>> The device ID should be 0xd300. This is the actual value read from the switch regs.
>>> This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
>> These are not real ID numbers, these are values that indicate the
>> generation of the switch being embedded into the SoC. Within
>> b53_common.c we don't have to differentiate a Starfighter 2 embedded in
>> BCM11360, NSP, or 7445 or 7278, which is why using 58XX_DEVICE_ID should
>> be good enough.
> Ok. Thanks.
>
> I was under the impression, that these id's could be used in the b53_switch_detect()
> API to auto detect the switch. In that API, the switch ID is read from the
> Management page register.
For external switches that is the case, but for internal/integrated
switches, the ID is not always representative of the switch. This is why
the choice of a chip-type ID was used here while adding support for NSP
to the b53 driver.
--
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: test_progs packed...
From: Alexei Starovoitov @ 2017-04-24 23:16 UTC (permalink / raw)
To: David Miller; +Cc: daniel, kafai, netdev
In-Reply-To: <20170424.190601.2066346847263955701.davem@davemloft.net>
On 4/24/17 4:06 PM, David Miller wrote:
>
> Alexei, why the packed attribute usage in test_progs.c?
>
> There should be no reason for this and it results in the object(s)
> having odd addresses (and thus be unaligned) on sparc.
because in:
static struct {
struct ethhdr eth;
struct iphdr iph;
struct tcphdr tcp;
} __packed pkt_v4 = {
iph is 4 byte aligned and eth is 2-byte.
We can add 2 byte hole in front of eth, but it's ugly since clean:
bpf_prog_test_run(prog_fd, 100000, &pkt_v4, sizeof(pkt_v4),
would need to deal with this extra padding explicitly.
It's only a user space thing and not in critical path,
so inefficient loads shouldn't be a problem.
You're bringing a good point that bpf_prog_test_run_skb() on
the kernel side should probably do:
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Arun Parameswaran @ 2017-04-24 23:15 UTC (permalink / raw)
To: Florian Fainelli, 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: <173c8ff2-6a31-5460-9a3f-8d8ac445a336-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 17-04-24 04:07 PM, Florian Fainelli wrote:
> On 04/24/2017 04:03 PM, Arun Parameswaran wrote:
>> Hi Eric
>>
>> A comment on the Device ID.
>>
>>
>> On 17-04-24 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>
>>> ---
>>> 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 },
>> The device ID should be 0xd300. This is the actual value read from the switch regs.
>> This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
> These are not real ID numbers, these are values that indicate the
> generation of the switch being embedded into the SoC. Within
> b53_common.c we don't have to differentiate a Starfighter 2 embedded in
> BCM11360, NSP, or 7445 or 7278, which is why using 58XX_DEVICE_ID should
> be good enough.
Ok. Thanks.
I was under the impression, that these id's could be used in the b53_switch_detect()
API to auto detect the switch. In that API, the switch ID is read from the
Management page register.
>>> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { /* sentinel */ },
>>> };
>> Other wise this patch set looks good.
>>
>> I was testing a similar change (except for the above, which doesn't
>> affect the functionality) to get the switch working and it works.
>>
>> Thanks
>> Arun
>>
>
--
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] sparc64: Support cbcond instructions in eBPF JIT.
From: Alexei Starovoitov @ 2017-04-24 23:09 UTC (permalink / raw)
To: David Miller, netdev; +Cc: daniel
In-Reply-To: <20170424.190228.571734658408906331.davem@davemloft.net>
On 4/24/17 4:02 PM, David Miller wrote:
>
> cbcond combines a compare with a branch into a single instruction.
>
> The limitations are:
>
> 1) Only newer chips support it
>
> 2) For immediate compares we are limited to 5-bit signed immediate
> values
>
> 3) The branch displacement is limited to 10-bit signed
>
> 4) We cannot use it for JSET
llvm doesn't know how to generate it yet. So it's only seen after
classic->extended conversion.
Hence not a concern at all for this optimization.
> Also, cbcond (unlike all other sparc control transfers) lacks a delay
> slot.
>
> Currently we don't have a useful instruction we can push into the
> delay slot of normal branches. So using cbcond pretty much always
> increases code density, and is therefore a win.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Nice!
Acked-by: Alexei Starovoitov <ast@kernel.org>
That puts up a pressure to optimize x64 JIT too :)
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Florian Fainelli @ 2017-04-24 23:07 UTC (permalink / raw)
To: Arun Parameswaran, Eric Anholt, 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
In-Reply-To: <ee265657-8175-b6c7-a0dc-cec216cd9ede@broadcom.com>
On 04/24/2017 04:03 PM, Arun Parameswaran wrote:
> Hi Eric
>
> A comment on the Device ID.
>
>
> On 17-04-24 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@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 },
> The device ID should be 0xd300. This is the actual value read from the switch regs.
> This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
These are not real ID numbers, these are values that indicate the
generation of the switch being embedded into the SoC. Within
b53_common.c we don't have to differentiate a Starfighter 2 embedded in
BCM11360, NSP, or 7445 or 7278, which is why using 58XX_DEVICE_ID should
be good enough.
>> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { /* sentinel */ },
>> };
> Other wise this patch set looks good.
>
> I was testing a similar change (except for the above, which doesn't
> affect the functionality) to get the switch working and it works.
>
> Thanks
> Arun
>
--
Florian
^ permalink raw reply
* test_progs packed...
From: David Miller @ 2017-04-24 23:06 UTC (permalink / raw)
To: ast; +Cc: daniel, kafai, netdev
Alexei, why the packed attribute usage in test_progs.c?
There should be no reason for this and it results in the object(s)
having odd addresses (and thus be unaligned) on sparc.
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Arun Parameswaran @ 2017-04-24 23:03 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, 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>
Hi Eric
A comment on the Device ID.
On 17-04-24 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>
> ---
> 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 },
The device ID should be 0xd300. This is the actual value read from the switch regs.
This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { /* sentinel */ },
> };
Other wise this patch set looks good.
I was testing a similar change (except for the above, which doesn't
affect the functionality) to get the switch working and it works.
Thanks
Arun
--
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
* [PATCH] sparc64: Support cbcond instructions in eBPF JIT.
From: David Miller @ 2017-04-24 23:02 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel
cbcond combines a compare with a branch into a single instruction.
The limitations are:
1) Only newer chips support it
2) For immediate compares we are limited to 5-bit signed immediate
values
3) The branch displacement is limited to 10-bit signed
4) We cannot use it for JSET
Also, cbcond (unlike all other sparc control transfers) lacks a delay
slot.
Currently we don't have a useful instruction we can push into the
delay slot of normal branches. So using cbcond pretty much always
increases code density, and is therefore a win.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Example output from "ALU_ADD_K: 0 + 0x80008000 = 0xffffffff80008000":
0000000000000000 <foo>:
0: 9d e3 bf 50 save %sp, -176, %sp
4: 01 00 00 00 nop
8: 90 10 00 18 mov %i0, %o0
c: 03 00 00 00 sethi %hi(0), %g1
10: 82 10 60 00 mov %g1, %g1 ! 0 <foo>
14: 13 00 00 00 sethi %hi(0), %o1
18: 92 12 60 00 mov %o1, %o1 ! 0 <foo>
1c: 83 28 70 20 sllx %g1, 0x20, %g1
20: 92 12 40 01 or %o1, %g1, %o1
24: 03 3f ff ff sethi %hi(0xfffffc00), %g1
28: 82 10 63 ff or %g1, 0x3ff, %g1 ! ffffffff <foo+0xffffffff>
2c: 15 20 00 20 sethi %hi(0x80008000), %o2
30: 94 12 a0 00 mov %o2, %o2 ! 80008000 <foo+0x80008000>
34: 83 28 70 20 sllx %g1, 0x20, %g1
38: 94 12 80 01 or %o2, %g1, %o2
3c: 03 1f ff df sethi %hi(0x7fff7c00), %g1
40: 82 18 7c 00 xor %g1, -1024, %g1
44: 92 02 40 01 add %o1, %g1, %o1
48: 12 e2 40 8a cxbe %o1, %o2, 58 <foo+0x58>
4c: 9a 10 20 02 mov 2, %o5
50: 10 60 00 03 b,pn %xcc, 5c <foo+0x5c>
54: 01 00 00 00 nop
58: 9a 10 20 01 mov 1, %o5 ! 1 <foo+0x1>
5c: 81 c7 e0 08 ret
60: 91 eb 40 00 restore %o5, %g0, %o0
arch/sparc/net/bpf_jit_comp_64.c | 238 ++++++++++++++++++++++++++++++---------
1 file changed, 184 insertions(+), 54 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp_64.c b/arch/sparc/net/bpf_jit_comp_64.c
index 43bef1c..2b2f3c3 100644
--- a/arch/sparc/net/bpf_jit_comp_64.c
+++ b/arch/sparc/net/bpf_jit_comp_64.c
@@ -18,6 +18,16 @@ static inline bool is_simm13(unsigned int value)
return value + 0x1000 < 0x2000;
}
+static inline bool is_simm10(unsigned int value)
+{
+ return value + 0x200 < 0x400;
+}
+
+static inline bool is_simm5(unsigned int value)
+{
+ return value + 0x10 < 0x20;
+}
+
static void bpf_flush_icache(void *start_, void *end_)
{
/* Cheetah's I-cache is fully coherent. */
@@ -39,6 +49,7 @@ static void bpf_flush_icache(void *start_, void *end_)
#define SEEN_MEM 4 /* use mem[] for temporary storage */
#define S13(X) ((X) & 0x1fff)
+#define S5(X) ((X) & 0x1f)
#define IMMED 0x00002000
#define RD(X) ((X) << 25)
#define RS1(X) ((X) << 14)
@@ -46,7 +57,8 @@ static void bpf_flush_icache(void *start_, void *end_)
#define OP(X) ((X) << 30)
#define OP2(X) ((X) << 22)
#define OP3(X) ((X) << 19)
-#define COND(X) ((X) << 25)
+#define COND(X) (((X) & 0xf) << 25)
+#define CBCOND(X) (((X) & 0x1f) << 25)
#define F1(X) OP(X)
#define F2(X, Y) (OP(X) | OP2(Y))
#define F3(X, Y) (OP(X) | OP3(Y))
@@ -75,10 +87,39 @@ static void bpf_flush_icache(void *start_, void *end_)
#define WDISP22(X) (((X) >> 2) & 0x3fffff)
#define WDISP19(X) (((X) >> 2) & 0x7ffff)
+/* The 10-bit branch displacement for CBCOND is split into two fields */
+static u32 WDISP10(u32 off)
+{
+ u32 ret = ((off >> 2) & 0xff) << 5;
+
+ ret |= ((off >> (2 + 8)) & 0x03) << 19;
+
+ return ret;
+}
+
+#define CBCONDE CBCOND(0x09)
+#define CBCONDLE CBCOND(0x0a)
+#define CBCONDL CBCOND(0x0b)
+#define CBCONDLEU CBCOND(0x0c)
+#define CBCONDCS CBCOND(0x0d)
+#define CBCONDN CBCOND(0x0e)
+#define CBCONDVS CBCOND(0x0f)
+#define CBCONDNE CBCOND(0x19)
+#define CBCONDG CBCOND(0x1a)
+#define CBCONDGE CBCOND(0x1b)
+#define CBCONDGU CBCOND(0x1c)
+#define CBCONDCC CBCOND(0x1d)
+#define CBCONDPOS CBCOND(0x1e)
+#define CBCONDVC CBCOND(0x1f)
+
+#define CBCONDGEU CBCONDCC
+#define CBCONDLU CBCONDCS
+
#define ANNUL (1 << 29)
#define XCC (1 << 21)
#define BRANCH (F2(0, 1) | XCC)
+#define CBCOND_OP (F2(0, 3) | XCC)
#define BA (BRANCH | CONDA)
#define BG (BRANCH | CONDG)
@@ -351,6 +392,22 @@ static void emit_branch(unsigned int br_opc, unsigned int from_idx, unsigned int
emit(br_opc | WDISP22(off << 2), ctx);
}
+static void emit_cbcond(unsigned int cb_opc, unsigned int from_idx, unsigned int to_idx,
+ const u8 dst, const u8 src, struct jit_ctx *ctx)
+{
+ unsigned int off = to_idx - from_idx;
+
+ emit(cb_opc | WDISP10(off << 2) | RS1(dst) | RS2(src), ctx);
+}
+
+static void emit_cbcondi(unsigned int cb_opc, unsigned int from_idx, unsigned int to_idx,
+ const u8 dst, s32 imm, struct jit_ctx *ctx)
+{
+ unsigned int off = to_idx - from_idx;
+
+ emit(cb_opc | IMMED | WDISP10(off << 2) | RS1(dst) | S5(imm), ctx);
+}
+
#define emit_read_y(REG, CTX) emit(RD_Y | RD(REG), CTX)
#define emit_write_y(REG, CTX) emit(WR_Y | IMMED | RS1(REG) | S13(0), CTX)
@@ -358,7 +415,7 @@ static void emit_branch(unsigned int br_opc, unsigned int from_idx, unsigned int
emit(SUBCC | RS1(R1) | RS2(R2) | RD(G0), CTX)
#define emit_cmpi(R1, IMM, CTX) \
- emit(SUBCC | IMMED | RS1(R1) | S13(IMM) | RD(G0), CTX);
+ emit(SUBCC | IMMED | RS1(R1) | S13(IMM) | RD(G0), CTX)
#define emit_btst(R1, R2, CTX) \
emit(ANDCC | RS1(R1) | RS2(R2) | RD(G0), CTX)
@@ -366,6 +423,117 @@ static void emit_branch(unsigned int br_opc, unsigned int from_idx, unsigned int
#define emit_btsti(R1, IMM, CTX) \
emit(ANDCC | IMMED | RS1(R1) | S13(IMM) | RD(G0), CTX)
+static int emit_compare_and_branch(const u8 code, const u8 dst, u8 src,
+ const s32 imm, bool is_imm, int branch_dst,
+ struct jit_ctx *ctx)
+{
+ bool use_cbcond = (sparc64_elf_hwcap & AV_SPARC_CBCOND) != 0;
+ const u8 tmp = bpf2sparc[TMP_REG_1];
+
+ branch_dst = ctx->offset[branch_dst];
+
+ if (!is_simm10(branch_dst - ctx->idx) ||
+ BPF_OP(code) == BPF_JSET)
+ use_cbcond = false;
+
+ if (is_imm) {
+ bool fits = true;
+
+ if (use_cbcond) {
+ if (!is_simm5(imm))
+ fits = false;
+ } else if (!is_simm13(imm)) {
+ fits = false;
+ }
+ if (!fits) {
+ ctx->tmp_1_used = true;
+ emit_loadimm_sext(imm, tmp, ctx);
+ src = tmp;
+ is_imm = false;
+ }
+ }
+
+ if (!use_cbcond) {
+ u32 br_opcode;
+
+ if (BPF_OP(code) == BPF_JSET) {
+ if (is_imm)
+ emit_btsti(dst, imm, ctx);
+ else
+ emit_btst(dst, src, ctx);
+ } else {
+ if (is_imm)
+ emit_cmpi(dst, imm, ctx);
+ else
+ emit_cmp(dst, src, ctx);
+ }
+ switch (BPF_OP(code)) {
+ case BPF_JEQ:
+ br_opcode = BE;
+ break;
+ case BPF_JGT:
+ br_opcode = BGU;
+ break;
+ case BPF_JGE:
+ br_opcode = BGEU;
+ break;
+ case BPF_JSET:
+ case BPF_JNE:
+ br_opcode = BNE;
+ break;
+ case BPF_JSGT:
+ br_opcode = BG;
+ break;
+ case BPF_JSGE:
+ br_opcode = BGE;
+ break;
+ default:
+ /* Make sure we dont leak kernel information to the
+ * user.
+ */
+ return -EFAULT;
+ }
+ emit_branch(br_opcode, ctx->idx, branch_dst, ctx);
+ emit_nop(ctx);
+ } else {
+ u32 cbcond_opcode;
+
+ switch (BPF_OP(code)) {
+ case BPF_JEQ:
+ cbcond_opcode = CBCONDE;
+ break;
+ case BPF_JGT:
+ cbcond_opcode = CBCONDGU;
+ break;
+ case BPF_JGE:
+ cbcond_opcode = CBCONDGEU;
+ break;
+ case BPF_JNE:
+ cbcond_opcode = CBCONDNE;
+ break;
+ case BPF_JSGT:
+ cbcond_opcode = CBCONDG;
+ break;
+ case BPF_JSGE:
+ cbcond_opcode = CBCONDGE;
+ break;
+ default:
+ /* Make sure we dont leak kernel information to the
+ * user.
+ */
+ return -EFAULT;
+ }
+ cbcond_opcode |= CBCOND_OP;
+ if (is_imm)
+ emit_cbcondi(cbcond_opcode, ctx->idx, branch_dst,
+ dst, imm, ctx);
+ else
+ emit_cbcond(cbcond_opcode, ctx->idx, branch_dst,
+ dst, src, ctx);
+ }
+ return 0;
+}
+
static void load_skb_regs(struct jit_ctx *ctx, u8 r_skb)
{
const u8 r_headlen = bpf2sparc[SKB_HLEN_REG];
@@ -765,44 +933,15 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
case BPF_JMP | BPF_JGE | BPF_X:
case BPF_JMP | BPF_JNE | BPF_X:
case BPF_JMP | BPF_JSGT | BPF_X:
- case BPF_JMP | BPF_JSGE | BPF_X: {
- u32 br_opcode;
+ case BPF_JMP | BPF_JSGE | BPF_X:
+ case BPF_JMP | BPF_JSET | BPF_X: {
+ int err;
- emit_cmp(dst, src, ctx);
-emit_cond_jmp:
- switch (BPF_OP(code)) {
- case BPF_JEQ:
- br_opcode = BE;
- break;
- case BPF_JGT:
- br_opcode = BGU;
- break;
- case BPF_JGE:
- br_opcode = BGEU;
- break;
- case BPF_JSET:
- case BPF_JNE:
- br_opcode = BNE;
- break;
- case BPF_JSGT:
- br_opcode = BG;
- break;
- case BPF_JSGE:
- br_opcode = BGE;
- break;
- default:
- /* Make sure we dont leak kernel information to the
- * user.
- */
- return -EFAULT;
- }
- emit_branch(br_opcode, ctx->idx, ctx->offset[i + off], ctx);
- emit_nop(ctx);
+ err = emit_compare_and_branch(code, dst, src, 0, false, i + off, ctx);
+ if (err)
+ return err;
break;
}
- case BPF_JMP | BPF_JSET | BPF_X:
- emit_btst(dst, src, ctx);
- goto emit_cond_jmp;
/* IF (dst COND imm) JUMP off */
case BPF_JMP | BPF_JEQ | BPF_K:
case BPF_JMP | BPF_JGT | BPF_K:
@@ -810,23 +949,14 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
case BPF_JMP | BPF_JNE | BPF_K:
case BPF_JMP | BPF_JSGT | BPF_K:
case BPF_JMP | BPF_JSGE | BPF_K:
- if (is_simm13(imm)) {
- emit_cmpi(dst, imm, ctx);
- } else {
- ctx->tmp_1_used = true;
- emit_loadimm_sext(imm, bpf2sparc[TMP_REG_1], ctx);
- emit_cmp(dst, bpf2sparc[TMP_REG_1], ctx);
- }
- goto emit_cond_jmp;
- case BPF_JMP | BPF_JSET | BPF_K:
- if (is_simm13(imm)) {
- emit_btsti(dst, imm, ctx);
- } else {
- ctx->tmp_1_used = true;
- emit_loadimm_sext(imm, bpf2sparc[TMP_REG_1], ctx);
- emit_btst(dst, bpf2sparc[TMP_REG_1], ctx);
- }
- goto emit_cond_jmp;
+ case BPF_JMP | BPF_JSET | BPF_K: {
+ int err;
+
+ err = emit_compare_and_branch(code, dst, 0, imm, true, i + off, ctx);
+ if (err)
+ return err;
+ break;
+ }
/* function call */
case BPF_JMP | BPF_CALL:
--
2.1.2.532.g19b5d50
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe
From: Singh, Krishneil K @ 2017-04-24 23:00 UTC (permalink / raw)
To: Song, Liwei (Wind River), Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
linux-kernel@vger.kernel.org, Song, Liwei (Wind River)
In-Reply-To: <1480909244-16460-1-git-send-email-liwei.song@windriver.com>
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Liwei Song
Sent: Sunday, December 4, 2016 7:41 PM
To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org; Song, Liwei (Wind River) <liwei.song@windriver.com>
Subject: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe
Fix the following CallTrace:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11 Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
00200086 00200086 eb5e1ab8 c144dd70 00000000 00000000 eb5e1af8 c10af89a
c1d23de4 eb5e1af8 00000009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 00000009 0000000a c1d32911 00000000 00000000 e44c826c eb5d8000 eb5e1b74 c10b214e Call Trace:
[<c144dd70>] dump_stack+0x5f/0x8f
[<c10af89a>] register_lock_class+0x25a/0x4c0 [<c10b14d8>] ? check_irq_usage+0x88/0xc0 [<c10b214e>] __lock_acquire+0x5e/0x17a0 [<c1abdb9b>] ? _raw_spin_unlock_irqrestore+0x3b/0x70
[<c10cf14a>] ? rcu_read_lock_sched_held+0x8a/0x90
[<c10b3c5f>] lock_acquire+0x9f/0x1f0
[<c1922dcf>] ? dev_get_stats+0x5f/0x110 [<c176e6b3>] ixgbe_get_stats64+0x113/0x320 [<c1922dcf>] ? dev_get_stats+0x5f/0x110 [<c1922dcf>] dev_get_stats+0x5f/0x110 [<c1ab5415>] rtnl_fill_stats+0x40/0x105 [<c193dd45>] rtnl_fill_ifinfo+0x4c5/0xd20 [<c11c5115>] ? __kmalloc_node_track_caller+0x1a5/0x410
[<c1917487>] ? __kmalloc_reserve.isra.42+0x27/0x80
[<c191754f>] ? __alloc_skb+0x6f/0x270
[<c1942291>] rtmsg_ifinfo_build_skb+0x71/0xd0 [<c194230a>] rtmsg_ifinfo.part.23+0x1a/0x50 [<c1923dad>] ? call_netdevice_notifiers_info+0x2d/0x60
[<c194236b>] rtmsg_ifinfo+0x2b/0x40
[<c192f997>] register_netdevice+0x3d7/0x4d0 [<c192faa7>] register_netdev+0x17/0x30 [<c177b83d>] ixgbe_probe+0x118d/0x1610 [<c1498202>] local_pci_probe+0x32/0x80 [<c1498172>] ? pci_match_device+0xd2/0x100 [<c14991e0>] pci_device_probe+0xc0/0x110 [<c1652cc5>] driver_probe_device+0x1c5/0x280 [<c1498172>] ? pci_match_device+0xd2/0x100 [<c1652e09>] __driver_attach+0x89/0x90 [<c1652d80>] ? driver_probe_device+0x280/0x280 [<c165114f>] bus_for_each_dev+0x4f/0x80 [<c165269e>] driver_attach+0x1e/0x20 [<c1652d80>] ? driver_probe_device+0x280/0x280 [<c1652317>] bus_add_driver+0x1a7/0x220 [<c1653a79>] driver_register+0x59/0xe0 [<c1f897b8>] ? igb_init_module+0x49/0x49 [<c1497b2a>] __pci_register_driver+0x4a/0x50 [<c1f8985d>] ixgbe_init_module+0xa5/0xc4 [<c1000485>] do_one_initcall+0x3
5/0x150 [<c107e818>] ? parameq+0x18/0x70 [<c1f395d8>] ? repair_env_string+0x12/0x51 [<c107ead0>] ? parse_args+0x260/0x3b0 [<c1074f73>] ? __usermodehelper_set_disable_depth+0x43/0x50
[<c1f39e90>] kernel_init_freeable+0x19b/0x267 [<c1f395c6>] ? set_debug_rodata+0xf/0xf [<c10b1e7b>] ? trace_hardirqs_on+0xb/0x10 [<c1abdc02>] ? _raw_spin_unlock_irq+0x32/0x50 [<c1085f0b>] ? finish_task_switch+0xab/0x1f0 [<c1085ec9>] ? finish_task_switch+0x69/0x1f0 [<c1ab6a30>] kernel_init+0x10/0x110 [<c108bd65>] ? schedule_tail+0x25/0x80 [<c1abe422>] ret_from_kernel_thread+0xe/0x24 [<c1ab6a20>] ? rest_init+0x130/0x130
This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING enabled.
This happens at ixgbe driver probe hardware stage, when comes to ixgbe_get_stats64, the seqcount/seqlock still not initialize, although this was initialize in TX/RX resources setup routin, but it was too late, then lockdep give this Warning.
To fix this, move the u64_stats_init function to driver probe stage, which before we get the status of seqcount and after the RX/TX ring was finished init.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
---
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
^ 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:58 UTC (permalink / raw)
To: David Miller
Cc: simon.horman, jiri, xiyou.wangcong, eric.dumazet, netdev, tom,
pablo
In-Reply-To: <20170424.182453.1488000441860994588.davem@davemloft.net>
On 17-04-24 06:24 PM, David Miller wrote:
>
> 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.
>
There is no work for me to do in tc if i push this in without
the liberal flag i was suggesting.
This is more about the next flag change that will fail with
older kernels unless the large tc change happens
i.e future ones after this kernel patch.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Scott Branden @ 2017-04-24 22:50 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, 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>
Minor comment in line
On 17-04-24 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>
> ---
> 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
> +
place in alphabetical order in the doc?
> 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 */ },
> };
>
--
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 0/3] net: dsa: b53: BCM58xx devices fixes
From: David Miller @ 2017-04-24 22:29 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, eric, jon.mason
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 24 Apr 2017 14:27:20 -0700
> This patch series contains fixes for the 58xx devices (Broadcom Northstar
> Plus), which were identified thanks to the help of Eric Anholt.
Series applied, thanks Florian.
^ permalink raw reply
* Re: Blogpost evaluation this [PATCH v4 net-next RFC] net: Generic XDP
From: David Miller @ 2017-04-24 22:26 UTC (permalink / raw)
To: brouer; +Cc: xdp-newbies, netdev, andy
In-Reply-To: <20170424162405.1183f2e7@redhat.com>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 24 Apr 2017 16:24:05 +0200
> I've done a very detailed evaluation of this patch, and I've created a
> blogpost like report here:
>
> https://prototype-kernel.readthedocs.io/en/latest/blogposts/xdp25_eval_generic_xdp_tx.html
Thanks for doing this Jesper.
> I didn't evaluate the adjust_head part, so I hope Andy is still
> planning to validate that part?
I was hoping he would post some results today as well.
Andy, how goes it? :)
Once the basic patch is ready and integrated in we can try to do
xmit_more in generic XDP and see what that does for XDP_TX
performance.
^ 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
* 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: 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: [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 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 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
* [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
* [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 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
* 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
* 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] 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
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