* [PATCH net-next 10/13] net: dsa: mv88e6xxx: Power on/off SERDES on cmode change
From: Andrew Lunn @ 2018-08-09 13:38 UTC (permalink / raw)
To: David Miller
Cc: netdev, Russell King, Florian Fainelli, nikita.yoush, Chris Healy,
marek.behun, Andrew Lunn
In-Reply-To: <1533821929-20071-1-git-send-email-andrew@lunn.ch>
The 6390 family has a number of SERDES interfaces per port. When the
cmode changes, eg 1000Base-X to XAUI, the SERDES interface in use will
also change. Power down the old SERDES interface and power up the new
SERDES interface.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/port.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index d236f3420f2d..977b4cb82299 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -19,6 +19,7 @@
#include "chip.h"
#include "port.h"
+#include "serdes.h"
int mv88e6xxx_port_read(struct mv88e6xxx_chip *chip, int port, int reg,
u16 *val)
@@ -372,6 +373,10 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
cmode = 0;
}
+ err = mv88e6390_serdes_power(chip, port, false);
+ if (err)
+ return err;
+
if (cmode) {
err = mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_STS, ®);
if (err)
@@ -383,6 +388,10 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
err = mv88e6xxx_port_write(chip, port, MV88E6XXX_PORT_STS, reg);
if (err)
return err;
+
+ err = mv88e6390_serdes_power(chip, port, true);
+ if (err)
+ return err;
}
chip->ports[port].cmode = cmode;
--
2.18.0
^ permalink raw reply related
* [PATCH net-next 11/13] net: dsa: mv88e6xxx: link mv88e6xxx_port to mv88e6xxx_chip
From: Andrew Lunn @ 2018-08-09 13:38 UTC (permalink / raw)
To: David Miller
Cc: netdev, Russell King, Florian Fainelli, nikita.yoush, Chris Healy,
marek.behun, Andrew Lunn
In-Reply-To: <1533821929-20071-1-git-send-email-andrew@lunn.ch>
An up coming change will register interrupts for individual switch
ports, using the mv88e6xxx_port as the interrupt context information.
Add members to the mv88e6xxx_port structure so we can link it back to
the mv88e6xxx_chip member the port belongs to and the port number of
the port.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 3 +++
drivers/net/dsa/mv88e6xxx/chip.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 66e0281604df..5845cbf7f096 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2173,6 +2173,9 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
int err;
u16 reg;
+ chip->ports[port].chip = chip;
+ chip->ports[port].port = port;
+
/* MAC Forcing register: don't force link, speed, duplex or flow control
* state to any particular values on physical ports, but force the CPU
* port and all DSA ports to their maximum bandwidth and full duplex.
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index 08c74c88dbde..577398fe36df 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -191,6 +191,8 @@ struct mv88e6xxx_port_hwtstamp {
};
struct mv88e6xxx_port {
+ struct mv88e6xxx_chip *chip;
+ int port;
u64 serdes_stats[2];
u64 atu_member_violation;
u64 atu_miss_violation;
--
2.18.0
^ permalink raw reply related
* [DO NOT MERGE] ARM: dts: vf610-zii-dev-rev-c: add support for SFF modules
From: Andrew Lunn @ 2018-08-09 13:43 UTC (permalink / raw)
To: netdev
Cc: Russell King, Florian Fainelli, nikita.yoush, Chris Healy,
marek.behun, Russell King, Andrew Lunn
From: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
For those wanting to test SFP on Devel C, here is the DTS changes. I
will submit these to arm-soc next cycle.
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 44 +++++++++++++----------
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index 0b1e94c6f25b..6f4a5602cefd 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -200,6 +200,13 @@
phy-handle = <&switch1phy4>;
};
+ port@9 {
+ reg = <9>;
+ label = "sff2";
+ phy-mode = "sgmii";
+ managed = "in-band-status";
+ sfp = <&sff2>;
+ };
switch1port10: port@10 {
reg = <10>;
@@ -245,6 +252,22 @@
#size-cells = <0>;
};
};
+
+ sff2: sff2 {
+ /* lower */
+ compatible = "sff,sff";
+ i2c-bus = <&sff2_i2c>;
+ los-gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ sff3: sff3 {
+ /* upper */
+ compatible = "sff,sff";
+ i2c-bus = <&sff3_i2c>;
+ los-gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>;
+ };
};
&dspi0 {
@@ -329,13 +352,6 @@
interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
gpio-controller;
interrupt-controller;
-
- enet_swr_en {
- gpio-hog;
- gpios = <0 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "enet-swr-en";
- };
};
/*
@@ -378,26 +394,16 @@
reg = <0>;
};
- i2c@1 {
+ sff2_i2c: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
-
- sfp2: at24c04@50 {
- compatible = "atmel,24c02";
- reg = <0x50>;
- };
};
- i2c@2 {
+ sff3_i2c: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
-
- sfp3: at24c04@50 {
- compatible = "atmel,24c02";
- reg = <0x50>;
- };
};
i2c@3 {
--
2.18.0
^ permalink raw reply related
* Re: [PATCH bpf-next] BPF: helpers: New helper to obtain namespace data from current task
From: Jesper Dangaard Brouer @ 2018-08-09 13:46 UTC (permalink / raw)
To: Carlos Neira; +Cc: brouer, netdev, ebiederm, quentin.monnet, ys114321
In-Reply-To: <20180809131800.11338-1-cneirabustos@gmail.com>
On Thu, 9 Aug 2018 09:18:00 -0400
Carlos Neira <cneirabustos@gmail.com> wrote:
> From: cneira <cneirabustos@gmail.com>
>
> This helper obtains the active namespace from current and returns pid, tgid,
> device and namespace id as seen from that namespace, allowing to instrument
> a process inside a container.
> Device is read from /proc/self/ns/pid, as in the future it's possible that
> different pid_ns files may belong to different devices, according
> to the discussion between Eric Biederman and Yonghong in 2017 linux plumbers
> conference.
>
> Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
> scripts but this helper returns the pid as seen by the root namespace which is
> fine when a bcc script is not executed inside a container.
> When the process of interest is inside a container, pid filtering will not work
> if bpf_get_current_pid_tgid() is used. This helper addresses this limitation
> returning the pid as it's seen by the current namespace where the script is
> executing.
>
> This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
> used to do pid filtering even inside a container.
>
> For example a bcc script using bpf_get_current_pid_tgid() (tools/funccount.py):
>
> u32 pid = bpf_get_current_pid_tgid() >> 32;
> if (pid != <pid_arg_passed_in>)
> return 0;
>
> Could be modified to use bpf_get_current_pidns_info() as follows:
>
> struct bpf_pidns pidns;
> bpf_get_current_pid_tgid(&pidns, sizeof(struct bpf_pidns));
^^^^^^^^^^^^^^^^^^^^^^^^
Shouldn't this be:
bpf_get_current_pidns_info(...)
> u32 pid = pidns.tgid;
> u32 nsid = pidns.nsid;
> if ((pid != <pid_arg_passed_in>) && (nsid != <nsid_arg_passed_in>))
> return 0;
>
[...]
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index dd5758dc35d3..031e7d9dba09 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -2113,6 +2113,18 @@ union bpf_attr {
> * the shared data.
> * Return
> * Pointer to the local storage area.
> + *
> + * int bpf_get_current_pidns(struct bpf_pidns_info *pidns, u32 size_of_pidns)
Should this be:
bpf_get_current_pidns_info(...)
> + * Description
> + * Copies into *pidns* pid, namespace id and tgid as seen by the
> + * current namespace and also device from /proc/self/ns/pid.
> + * *size_of_pidns* must be the size of *pidns*
> + *
> + * This helper is used when pid filtering is needed inside a
> + * container as bpf_get_current_tgid() helper returns always the
> + * pid id as seen by the root namespace.
> + * Return
> + * 0 on success -EINVAL on error.
> */
> #define __BPF_FUNC_MAPPER(FN) \
> FN(unspec), \
> @@ -2196,7 +2208,8 @@ union bpf_attr {
> FN(rc_keydown), \
> FN(skb_cgroup_id), \
> FN(get_current_cgroup_id), \
> - FN(get_local_storage),
> + FN(get_local_storage), \
> + FN(get_current_pidns_info),
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* C45 support and mdiobus_scan
From: Jose Abreu @ 2018-08-09 13:54 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi All,
I'm preparing to add support for 10G in stmmac and I noticed that
Generic 10G PHY needs C45 support. Digging through the
registration callbacks for phy that are used in stmmac I reached
to mdiobus_scan() and the following call:
phydev = get_phy_device(bus, addr, false);
The last parameter is "is_c45", and is always being set to false ...
Does this mean that I can't use the Generic 10G PHY in stmmac? I
don't mind link being fixed for 10G for now.
(Notice I'm using a PCI based setup so no DT bindings can help me
for this).
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Contact my secretary in Burkina-Faso
From: Dr. Gilmore Carson @ 2018-08-09 13:58 UTC (permalink / raw)
Dear Friend,
Good day, this is Mr. Henri Zongo, I'm happy to inform you about my success in getting the fund $29.6Million transferred under the co-operation of a new partner from Dubai, Presently I'm in Dubai for investment projects with my own share of the total sum. Meanwhile,I didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us some how.
Now contact my secretary in Burkina-Faso, his name is Mr. Leonard Kabore and his email address is (leonard_kabore@outlook.com) and ask him to send you VISA ATM CARD which has loaded the sum of USD$1,000,000.00 (One Million United States Dollars issued in your name by our Bank (BOA) headquarter, this is for your compensation for all the past efforts and attempts to assist me in this matter. Note, you will withdraw your money in an ATM MACHINE in any part of the world, but the maximum is ($5,000) Fifteen Thousand Us Dollars in three transactions per day.
So feel free and get in touched with my secretary and instruct him where to send the VISA ATM CARD to you. Please do let me know immediately you receive the ATM CARD so that we can share the joy. Please my main reason to compensate you with this amount is for you to keep your mouth shut, do not allow anybody to know about this deal ever, let it to be sealed between us because I don't want to have any problem in the future please!.
This is how we contributed for your compensation, I contributed $600,000 dollars out of my own share while my new partner contributed, $400,000 dollars to make the total of $1,000,000.00 USD,please let the deal be sealed ok! delete every message you received so far concerning this deal in your mailbox.
In the moment, I am very busy here because of the investment projects which me and the new partner are having at hand, finally, remember that I had forwarded instruction to my secretary on your behalf to receive that VISA ATM CARD, so feel free to get in touch with him and he will help you to send it to your address. I will be traveling to Qatar this evening with my partner for an investment project.
Regards,
Mr. Henri Zongo.
Contact my secretary in Burkina-Faso
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix bpffs non-array map seq_show issue
From: Daniel Borkmann @ 2018-08-09 14:24 UTC (permalink / raw)
To: Yonghong Song, Alexei Starovoitov; +Cc: ast, netdev, kernel-team
In-Reply-To: <c5f1bd74-f411-25c1-7bfb-b709e6746924@fb.com>
On 08/09/2018 05:55 AM, Yonghong Song wrote:
> On 8/8/18 7:25 PM, Alexei Starovoitov wrote:
>> On Wed, Aug 08, 2018 at 06:25:19PM -0700, Yonghong Song wrote:
>>> In function map_seq_next() of kernel/bpf/inode.c,
>>> the first key will be the "0" regardless of the map type.
>>> This works for array. But for hash type, if it happens
>>> key "0" is in the map, the bpffs map show will miss
>>> some items if the key "0" is not the first element of
>>> the first bucket.
>>>
>>> This patch fixed the issue by guaranteeing to get
>>> the first element, if the seq_show is just started,
>>> by passing NULL pointer key to map_get_next_key() callback.
>>> This way, no missing elements will occur for
>>> bpffs hash table show even if key "0" is in the map.
>
> Currently, map_seq_show_elem callback is only implemented
> for arraymap. So the problem actually is not exposed.
>
> The issue is discovered when I tried to implement
> map_seq_show_elem for hash maps, and I will have followup
> patches for it.
>
> So this patch probably should apply to bpf-next or
> I can include this patch in my later patch set
> which implements map_seq_show_elem for hash map
> which can demonstrate the problem.
>
> Please let me know.
>
>>> Fixes: a26ca7c982cb5 ("bpf: btf: Add pretty print support to the basic arraymap")
>>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>
>> Acked-by: Alexei Starovoitov <ast@kernel.org>
Given this doesn't affect any current code, I think bpf-next
would be fine.
Anyway, this cannot be used as-is, results in following compile
warning ...
# make -j4 kernel/bpf/
DESCEND objtool
CALL scripts/checksyscalls.sh
CC kernel/bpf/verifier.o
CC kernel/bpf/inode.o
kernel/bpf/inode.c: In function ‘map_seq_next’:
kernel/bpf/inode.c:214:1: warning: label ‘done’ defined but not used [-Wunused-label]
done:
^~~~
AR kernel/bpf/built-in.a
^ permalink raw reply
* Re: [PATCH bpf-next] BPF: helpers: New helper to obtain namespace data from current task
From: Carlos Neira @ 2018-08-09 14:49 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Carlos Neira, netdev, ebiederm, quentin.monnet, ys114321
In-Reply-To: <20180809154653.40396ce3@redhat.com>
Yes, you are right. I'll resubmit the patch with those corrections.
Thanks a lot for catching this.
Thu, Aug 09, 2018 at 03:46:53PM +0200, Jesper Dangaard Brouer wrote:
> On Thu, 9 Aug 2018 09:18:00 -0400
> Carlos Neira <cneirabustos@gmail.com> wrote:
>
> > From: cneira <cneirabustos@gmail.com>
> >
> > This helper obtains the active namespace from current and returns pid, tgid,
> > device and namespace id as seen from that namespace, allowing to instrument
> > a process inside a container.
> > Device is read from /proc/self/ns/pid, as in the future it's possible that
> > different pid_ns files may belong to different devices, according
> > to the discussion between Eric Biederman and Yonghong in 2017 linux plumbers
> > conference.
> >
> > Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
> > scripts but this helper returns the pid as seen by the root namespace which is
> > fine when a bcc script is not executed inside a container.
> > When the process of interest is inside a container, pid filtering will not work
> > if bpf_get_current_pid_tgid() is used. This helper addresses this limitation
> > returning the pid as it's seen by the current namespace where the script is
> > executing.
> >
> > This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
> > used to do pid filtering even inside a container.
> >
> > For example a bcc script using bpf_get_current_pid_tgid() (tools/funccount.py):
> >
> > u32 pid = bpf_get_current_pid_tgid() >> 32;
> > if (pid != <pid_arg_passed_in>)
> > return 0;
> >
> > Could be modified to use bpf_get_current_pidns_info() as follows:
> >
> > struct bpf_pidns pidns;
> > bpf_get_current_pid_tgid(&pidns, sizeof(struct bpf_pidns));
> ^^^^^^^^^^^^^^^^^^^^^^^^
>
> Shouldn't this be:
> bpf_get_current_pidns_info(...)
>
> > u32 pid = pidns.tgid;
> > u32 nsid = pidns.nsid;
> > if ((pid != <pid_arg_passed_in>) && (nsid != <nsid_arg_passed_in>))
> > return 0;
> >
>
> [...]
>
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index dd5758dc35d3..031e7d9dba09 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -2113,6 +2113,18 @@ union bpf_attr {
> > * the shared data.
> > * Return
> > * Pointer to the local storage area.
> > + *
> > + * int bpf_get_current_pidns(struct bpf_pidns_info *pidns, u32 size_of_pidns)
>
> Should this be:
> bpf_get_current_pidns_info(...)
>
> > + * Description
> > + * Copies into *pidns* pid, namespace id and tgid as seen by the
> > + * current namespace and also device from /proc/self/ns/pid.
> > + * *size_of_pidns* must be the size of *pidns*
> > + *
> > + * This helper is used when pid filtering is needed inside a
> > + * container as bpf_get_current_tgid() helper returns always the
> > + * pid id as seen by the root namespace.
> > + * Return
> > + * 0 on success -EINVAL on error.
> > */
> > #define __BPF_FUNC_MAPPER(FN) \
> > FN(unspec), \
> > @@ -2196,7 +2208,8 @@ union bpf_attr {
> > FN(rc_keydown), \
> > FN(skb_cgroup_id), \
> > FN(get_current_cgroup_id), \
> > - FN(get_local_storage),
> > + FN(get_local_storage), \
> > + FN(get_current_pidns_info),
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH bpf-next 1/3] bpf: add bpf queue map
From: Mauricio Vasquez @ 2018-08-09 14:51 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: Alexei Starovoitov, netdev
In-Reply-To: <ca4532da-de68-6308-e969-2061b037c571@iogearbox.net>
On 08/09/2018 04:02 AM, Daniel Borkmann wrote:
> On 08/09/2018 06:48 AM, Alexei Starovoitov wrote:
>> On Wed, Aug 08, 2018 at 10:08:47PM -0500, Mauricio Vasquez wrote:
>>>> And how about adding three new helpers: push/pop/peek as well?
>>>> Reusing lookup/update is neat, but does lookup == pop
>>>> or does lookup == peek ?
>>>> I suspect it will be confusing.
>>>> Three new helpers cost nothing, but will make bpf progs easier to read.
>>> I agree. I have one doubt here, update/lookup/delete is implemented in all
>>> map types, if the operation is not supported it returns -EINVAL.
>>> For push/pop/peek, should we implement it in all maps or is it better to
>>> check the map type before invoking map->ops->push/pop/seek?
>>> (Maybe checking if map->ops->xxx is NULL will also work)
>> Since push/pop/peak are only for this queue/stack I thought we won't
>> be adding 'ops' for them and just call the helpers from progs.
>> But now I'm having second thoughts, since 3 new commands for syscall
>> feels like overkill.
>> At the same time I still don't feel that lookup == pop is the right alias.
>> Also what peak is going to alias to ?
>> May be let's go back to your original idea with a tweak:
>> push == update
>> peak == lookup
>> pop = lookup + delete
>> In other words in case of stack the bpf_map_lookup_elem will return
>> the pointer to value of top element in the stack and
>> bpf_map_delete_elem will delete that top element.
>> Then in user space we can introduce push/pop always_inline functions like:
>> void bpf_push(struct bpf_map *map, void *value)
>> {
>> bpf_map_update_elem(map, NULL/*key*/, value);
>> }
>>
>> void *bpf_pop(struct bpf_map *map)
>> {
>> void * val = bpf_map_lookup_elem(map, NULL/*key*/);
>> bpf_map_delete_elem(map, NULL/*key*/);
>> return val;
>> }
>>
>> Thoughts?
> I actually think that having new push/peak/pop BPF map helpers would
> be fine, as well as having them sit in map->ops. Initially I'd probably
> leave out the syscall ops counterparts so they can be used only from
> program.
I also think that having the new helpers is good. I don't have a strong
opinion about saving them in map->ops or not, in any case it has to be
verified that push/pop/peek are only invoked in stack/queue maps. I
think we could force in on the verifier, would it be ok?
> Potentially array and per-cpu array could implement them even by having
> an internal pointer to the current slot which we move on push/pop. This
> would potentially also avoid all the RCU callbacks to free the elements,
> elem allocations, list locking, and improve cache locality compared to
> the current implementation.
I could change the implementation, a linked list is used when
BPF_F_NO_PREALLOC is passed, otherwise a plain array with internal
indexes is used.
I have a question about RCU and a possible array-based implementation.
It should be guarantee that a pointer from a pop() operation is valid
for the whole program duration.
If an eBPF program A calls pop() it will get a pointer to the head in
the array, and the head index will move, it is possible that a second
program B (running on a different CPU) pushes a new element overwriting
the element pointed by A.
I think we need to use a more sophisticated mechanism than just an array
and two indexes. Am I missing something?
> Agree that existing ops are not the right alias, but deferring to user
> space as inline function also doesn't really seem like a good fit, imho,
> so I'd prefer rather to have something native. (Aside from that, the
> above inline bpf_pop() would also race between CPUs.)
I think we should have push/pop/peek syscalls as well, having a
bpf_pop() that is race prone would create problems. Users expected maps
operations to be safe, so having one that is not will confuse them.
> Thanks,
> Daniel
>
Thanks,
Mauricio.
^ permalink raw reply
* Re: [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Anssi Hannula @ 2018-08-09 14:54 UTC (permalink / raw)
To: Claudiu Beznea; +Cc: Nicolas Ferre, David S. Miller, netdev
In-Reply-To: <425ed5af-eac2-a58b-b6ca-f022a80367e4@microchip.com>
On 9.8.2018 11:26, Claudiu Beznea wrote:
> On 08.08.2018 15:19, Anssi Hannula wrote:
>> macb_close() calls macb_reset_hw() which zeroes NCR register, including
>> the MPE (Management Port Enable) bit.
>>
>> This will prevent accessing any other PHYs for other Ethernet MACs on
>> the MDIO bus which is still registered.
>>
>> Fix that by keeping the MPE bit set.
>>
>> Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
>> ---
>> drivers/net/ethernet/cadence/macb_main.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>> index dc09f9a8a49b..3ca98fc32144 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -2030,12 +2030,13 @@ static void macb_reset_hw(struct macb *bp)
>> unsigned int q;
>>
>> /* Disable RX and TX (XXX: Should we halt the transmission
>> - * more gracefully?)
>> + * more gracefully?) but keep management port open since there
>> + * may be other users of the mdio bus
>> */
>> - macb_writel(bp, NCR, 0);
>> + macb_writel(bp, NCR, MACB_BIT(MPE));
> Would be better to read the NCR and clear only RX and TX bits, something like:
> val = macb_readl(bp, NCR);
>
> /* Disable TX and RX. */
> val &= ~(MACB_BIT(TE) | MACB_BIT(RE));
>
> /* Clear statistics */
> val |= MACB_BIT(CLRSTAT);
>
> macb_writel(bp, NCR, val);
>
> MPE should have been enabled by previous operations.
macb_reset_hw() is called in init path too, though, so maybe clearing
all bits is intentional / wanted to get the controller to a known state,
even though the comment only mentions TX/RX?
If so, maybe the below would be better? But if you think just clearing
TE/RE is better I'll just do it like you suggested.
val = macb_readl(bp, NCR);
/* Keep only MDIO port active */
val &= MACB_BIT(MPE);
/* Clear statistics */
val |= MACB_BIT(CLRSTAT);
macb_writel(bp, NCR, val);
> Thank you,
> Claudiu Beznea
>
>>
>> /* Clear the stats registers (XXX: Update stats first?) */
>> - macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
>> + macb_writel(bp, NCR, MACB_BIT(CLRSTAT) | MACB_BIT(MPE));
>>
>> /* Clear all status flags */
>> macb_writel(bp, TSR, -1);
>>
--
Anssi Hannula / Bitwise Oy
+358 503803997
^ permalink raw reply
* [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Eelco Chaudron @ 2018-08-09 15:01 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, jiri
Add hardware specific counters to TC actions which will be exported
through the netlink API. This makes troubleshooting TC flower offload
easier, as it possible to differentiate the packets being offloaded.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Eelco Chaudron (2):
net/core: Add new basic hardware counter
net/sched: Add hardware specific counters to TC actions
include/net/act_api.h | 8 +++-
include/net/gen_stats.h | 4 ++
include/net/pkt_cls.h | 2 +
include/uapi/linux/gen_stats.h | 1 +
net/core/gen_stats.c | 73 ++++++++++++++++++++++++++++++----------
net/sched/act_api.c | 14 ++++++--
net/sched/act_gact.c | 6 +++
net/sched/act_mirred.c | 5 ++-
8 files changed, 85 insertions(+), 28 deletions(-)
^ permalink raw reply
* [PATCH 1/2] net/core: Add new basic hardware counter
From: Eelco Chaudron @ 2018-08-09 15:01 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, jiri
In-Reply-To: <20180809150118.5275.63824.stgit@wsfd-netdev20.ntdv.lab.eng.bos.redhat.com>
Add a new hardware specific basic counter, TCA_STATS_BASIC_HW. This can
be used to count packets/bytes processed by hardware offload.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
include/net/gen_stats.h | 4 ++
include/uapi/linux/gen_stats.h | 1 +
net/core/gen_stats.c | 73 ++++++++++++++++++++++++++++++----------
3 files changed, 59 insertions(+), 19 deletions(-)
diff --git a/include/net/gen_stats.h b/include/net/gen_stats.h
index 0304ba2..7e54a9a 100644
--- a/include/net/gen_stats.h
+++ b/include/net/gen_stats.h
@@ -44,6 +44,10 @@ void __gnet_stats_copy_basic(const seqcount_t *running,
struct gnet_stats_basic_packed *bstats,
struct gnet_stats_basic_cpu __percpu *cpu,
struct gnet_stats_basic_packed *b);
+int gnet_stats_copy_basic_hw(const seqcount_t *running,
+ struct gnet_dump *d,
+ struct gnet_stats_basic_cpu __percpu *cpu,
+ struct gnet_stats_basic_packed *b);
int gnet_stats_copy_rate_est(struct gnet_dump *d,
struct net_rate_estimator __rcu **ptr);
int gnet_stats_copy_queue(struct gnet_dump *d,
diff --git a/include/uapi/linux/gen_stats.h b/include/uapi/linux/gen_stats.h
index 24a861c..065408e 100644
--- a/include/uapi/linux/gen_stats.h
+++ b/include/uapi/linux/gen_stats.h
@@ -12,6 +12,7 @@ enum {
TCA_STATS_APP,
TCA_STATS_RATE_EST64,
TCA_STATS_PAD,
+ TCA_STATS_BASIC_HW,
__TCA_STATS_MAX,
};
#define TCA_STATS_MAX (__TCA_STATS_MAX - 1)
diff --git a/net/core/gen_stats.c b/net/core/gen_stats.c
index 188d693..65a2e82 100644
--- a/net/core/gen_stats.c
+++ b/net/core/gen_stats.c
@@ -162,30 +162,18 @@
}
EXPORT_SYMBOL(__gnet_stats_copy_basic);
-/**
- * gnet_stats_copy_basic - copy basic statistics into statistic TLV
- * @running: seqcount_t pointer
- * @d: dumping handle
- * @cpu: copy statistic per cpu
- * @b: basic statistics
- *
- * Appends the basic statistics to the top level TLV created by
- * gnet_stats_start_copy().
- *
- * Returns 0 on success or -1 with the statistic lock released
- * if the room in the socket buffer was not sufficient.
- */
int
-gnet_stats_copy_basic(const seqcount_t *running,
- struct gnet_dump *d,
- struct gnet_stats_basic_cpu __percpu *cpu,
- struct gnet_stats_basic_packed *b)
+___gnet_stats_copy_basic(const seqcount_t *running,
+ struct gnet_dump *d,
+ struct gnet_stats_basic_cpu __percpu *cpu,
+ struct gnet_stats_basic_packed *b,
+ int type)
{
struct gnet_stats_basic_packed bstats = {0};
__gnet_stats_copy_basic(running, &bstats, cpu, b);
- if (d->compat_tc_stats) {
+ if (d->compat_tc_stats && type == TCA_STATS_BASIC) {
d->tc_stats.bytes = bstats.bytes;
d->tc_stats.packets = bstats.packets;
}
@@ -196,14 +184,61 @@
memset(&sb, 0, sizeof(sb));
sb.bytes = bstats.bytes;
sb.packets = bstats.packets;
- return gnet_stats_copy(d, TCA_STATS_BASIC, &sb, sizeof(sb),
+ return gnet_stats_copy(d, type, &sb, sizeof(sb),
TCA_STATS_PAD);
}
return 0;
}
+
+/**
+ * gnet_stats_copy_basic - copy basic statistics into statistic TLV
+ * @running: seqcount_t pointer
+ * @d: dumping handle
+ * @cpu: copy statistic per cpu
+ * @b: basic statistics
+ *
+ * Appends the basic statistics to the top level TLV created by
+ * gnet_stats_start_copy().
+ *
+ * Returns 0 on success or -1 with the statistic lock released
+ * if the room in the socket buffer was not sufficient.
+ */
+int
+gnet_stats_copy_basic(const seqcount_t *running,
+ struct gnet_dump *d,
+ struct gnet_stats_basic_cpu __percpu *cpu,
+ struct gnet_stats_basic_packed *b)
+{
+ return ___gnet_stats_copy_basic(running, d, cpu, b,
+ TCA_STATS_BASIC);
+}
EXPORT_SYMBOL(gnet_stats_copy_basic);
/**
+ * gnet_stats_copy_basic_hw - copy basic hw statistics into statistic TLV
+ * @running: seqcount_t pointer
+ * @d: dumping handle
+ * @cpu: copy statistic per cpu
+ * @b: basic statistics
+ *
+ * Appends the basic statistics to the top level TLV created by
+ * gnet_stats_start_copy().
+ *
+ * Returns 0 on success or -1 with the statistic lock released
+ * if the room in the socket buffer was not sufficient.
+ */
+int
+gnet_stats_copy_basic_hw(const seqcount_t *running,
+ struct gnet_dump *d,
+ struct gnet_stats_basic_cpu __percpu *cpu,
+ struct gnet_stats_basic_packed *b)
+{
+ return ___gnet_stats_copy_basic(running, d, cpu, b,
+ TCA_STATS_BASIC_HW);
+}
+EXPORT_SYMBOL(gnet_stats_copy_basic_hw);
+
+/**
* gnet_stats_copy_rate_est - copy rate estimator statistics into statistics TLV
* @d: dumping handle
* @rate_est: rate estimator
^ permalink raw reply related
* [PATCH 2/2] net/sched: Add hardware specific counters to TC actions
From: Eelco Chaudron @ 2018-08-09 15:01 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, jiri
In-Reply-To: <20180809150118.5275.63824.stgit@wsfd-netdev20.ntdv.lab.eng.bos.redhat.com>
Add additional counters that will store the bytes/packets processed by
hardware. These will be exported through the netlink interface for
displaying by the iproute2 tc tool
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
include/net/act_api.h | 8 +++++---
include/net/pkt_cls.h | 2 +-
net/sched/act_api.c | 14 +++++++++++---
net/sched/act_gact.c | 6 +++++-
net/sched/act_mirred.c | 5 ++++-
5 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/include/net/act_api.h b/include/net/act_api.h
index 8c9bc02..9931d8a 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -33,10 +33,12 @@ struct tc_action {
int tcfa_action;
struct tcf_t tcfa_tm;
struct gnet_stats_basic_packed tcfa_bstats;
+ struct gnet_stats_basic_packed tcfa_bstats_hw;
struct gnet_stats_queue tcfa_qstats;
struct net_rate_estimator __rcu *tcfa_rate_est;
spinlock_t tcfa_lock;
struct gnet_stats_basic_cpu __percpu *cpu_bstats;
+ struct gnet_stats_basic_cpu __percpu *cpu_bstats_hw;
struct gnet_stats_queue __percpu *cpu_qstats;
struct tc_cookie __rcu *act_cookie;
struct tcf_chain *goto_chain;
@@ -98,7 +100,7 @@ struct tc_action_ops {
struct netlink_callback *, int,
const struct tc_action_ops *,
struct netlink_ext_ack *);
- void (*stats_update)(struct tc_action *, u64, u32, u64);
+ void (*stats_update)(struct tc_action *, u64, u32, u64, bool);
size_t (*get_fill_size)(const struct tc_action *act);
struct net_device *(*get_dev)(const struct tc_action *a);
int (*delete)(struct net *net, u32 index);
@@ -189,13 +191,13 @@ int tcf_action_dump(struct sk_buff *skb, struct tc_action *actions[], int bind,
#endif /* CONFIG_NET_CLS_ACT */
static inline void tcf_action_stats_update(struct tc_action *a, u64 bytes,
- u64 packets, u64 lastuse)
+ u64 packets, u64 lastuse, bool hw)
{
#ifdef CONFIG_NET_CLS_ACT
if (!a->ops->stats_update)
return;
- a->ops->stats_update(a, bytes, packets, lastuse);
+ a->ops->stats_update(a, bytes, packets, lastuse, hw);
#endif
}
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index ef727f7..de1f06a 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -324,7 +324,7 @@ static inline void tcf_exts_to_list(const struct tcf_exts *exts,
for (i = 0; i < exts->nr_actions; i++) {
struct tc_action *a = exts->actions[i];
- tcf_action_stats_update(a, bytes, packets, lastuse);
+ tcf_action_stats_update(a, bytes, packets, lastuse, true);
}
preempt_enable();
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 229d63c..9ab3061 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -81,6 +81,7 @@ static void tcf_set_action_cookie(struct tc_cookie __rcu **old_cookie,
static void free_tcf(struct tc_action *p)
{
free_percpu(p->cpu_bstats);
+ free_percpu(p->cpu_bstats_hw);
free_percpu(p->cpu_qstats);
tcf_set_action_cookie(&p->act_cookie, NULL);
@@ -390,9 +391,12 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
p->cpu_bstats = netdev_alloc_pcpu_stats(struct gnet_stats_basic_cpu);
if (!p->cpu_bstats)
goto err1;
+ p->cpu_bstats_hw = netdev_alloc_pcpu_stats(struct gnet_stats_basic_cpu);
+ if (!p->cpu_bstats_hw)
+ goto err2;
p->cpu_qstats = alloc_percpu(struct gnet_stats_queue);
if (!p->cpu_qstats)
- goto err2;
+ goto err3;
}
spin_lock_init(&p->tcfa_lock);
p->tcfa_index = index;
@@ -404,7 +408,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
&p->tcfa_rate_est,
&p->tcfa_lock, NULL, est);
if (err)
- goto err3;
+ goto err4;
}
p->idrinfo = idrinfo;
@@ -412,8 +416,10 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
INIT_LIST_HEAD(&p->list);
*a = p;
return 0;
-err3:
+err4:
free_percpu(p->cpu_qstats);
+err3:
+ free_percpu(p->cpu_bstats_hw);
err2:
free_percpu(p->cpu_bstats);
err1:
@@ -988,6 +994,8 @@ int tcf_action_copy_stats(struct sk_buff *skb, struct tc_action *p,
goto errout;
if (gnet_stats_copy_basic(NULL, &d, p->cpu_bstats, &p->tcfa_bstats) < 0 ||
+ gnet_stats_copy_basic_hw(NULL, &d, p->cpu_bstats_hw,
+ &p->tcfa_bstats_hw) < 0 ||
gnet_stats_copy_rate_est(&d, &p->tcfa_rate_est) < 0 ||
gnet_stats_copy_queue(&d, p->cpu_qstats,
&p->tcfa_qstats,
diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
index 661b72b..1fe6825 100644
--- a/net/sched/act_gact.c
+++ b/net/sched/act_gact.c
@@ -155,7 +155,7 @@ static int tcf_gact(struct sk_buff *skb, const struct tc_action *a,
}
static void tcf_gact_stats_update(struct tc_action *a, u64 bytes, u32 packets,
- u64 lastuse)
+ u64 lastuse, bool hw)
{
struct tcf_gact *gact = to_gact(a);
int action = READ_ONCE(gact->tcf_action);
@@ -166,6 +166,10 @@ static void tcf_gact_stats_update(struct tc_action *a, u64 bytes, u32 packets,
if (action == TC_ACT_SHOT)
this_cpu_ptr(gact->common.cpu_qstats)->drops += packets;
+ if (hw)
+ _bstats_cpu_update(this_cpu_ptr(gact->common.cpu_bstats_hw),
+ bytes, packets);
+
tm->lastuse = max_t(u64, tm->lastuse, lastuse);
}
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index b26d060..c193583 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -273,12 +273,15 @@ static int tcf_mirred(struct sk_buff *skb, const struct tc_action *a,
}
static void tcf_stats_update(struct tc_action *a, u64 bytes, u32 packets,
- u64 lastuse)
+ u64 lastuse, bool hw)
{
struct tcf_mirred *m = to_mirred(a);
struct tcf_t *tm = &m->tcf_tm;
_bstats_cpu_update(this_cpu_ptr(a->cpu_bstats), bytes, packets);
+ if (hw)
+ _bstats_cpu_update(this_cpu_ptr(a->cpu_bstats_hw),
+ bytes, packets);
tm->lastuse = max_t(u64, tm->lastuse, lastuse);
}
^ permalink raw reply related
* Re: C45 support and mdiobus_scan
From: Andrew Lunn @ 2018-08-09 15:03 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <3bbd1d78-b896-2a81-83cf-7dad2f73bae9@synopsys.com>
On Thu, Aug 09, 2018 at 02:54:11PM +0100, Jose Abreu wrote:
> Hi All,
>
> I'm preparing to add support for 10G in stmmac and I noticed that
> Generic 10G PHY needs C45 support. Digging through the
> registration callbacks for phy that are used in stmmac I reached
> to mdiobus_scan() and the following call:
>
> phydev = get_phy_device(bus, addr, false);
>
> The last parameter is "is_c45", and is always being set to false ...
>
> Does this mean that I can't use the Generic 10G PHY in stmmac? I
> don't mind link being fixed for 10G for now.
Hi Jose
So far, all MACs which support 10G have used phy-handle to point to a
PHY on am MDIO bus, and that PHY uses .compatible =
"ethernet-phy-ieee802.3-c45". of_mdiobus_register() will then find the
PHY and register it. You really should try to follow this, if you can.
> (Notice I'm using a PCI based setup so no DT bindings can help me
> for this).
That is not necessarily true. Take a look at:
arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
status = "okay";
host@0 {
reg = <0 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
i210: i210@0 {
reg = <0 0 0 0 0>;
};
};
};
The PCIe core will look in the device tree and when it creates the
platform device for the i210 on the pcie bus, it points
pdev->dev.of_node at this node. So long as you are using a platform
with DT, you can do this. I hope you are not using x86..
Andrew
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Lad, Prabhakar @ 2018-08-09 15:07 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180809125637.GC1813@lunn.ch>
Hi,
On Thu, Aug 9, 2018 at 1:56 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Aug 09, 2018 at 01:45:52PM +0100, Lad, Prabhakar wrote:
> > On Thu, Aug 9, 2018 at 1:02 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Thu, Aug 09, 2018 at 12:31:31PM +0100, Lad, Prabhakar wrote:
> > > > Hi Andrew,
> > > >
> > > > On Thu, Aug 2, 2018 at 5:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > > > >
> > > > > > I dont see any Reply's on the PC with tcpdump on PC
> > > > >
> > > > > So try ethool -S on the PC. Any packets dropped because of errors?
> > > > >
> > > > I dont see any drops/errors on the PC, following is the dump from PC:
> > > >
> > > > sudo ethtool -S enx00e04c68c229
> > > > [sudo] password for prabhakar:
> > > > NIC statistics:
> > > > tx_packets: 1659
> > > > rx_packets: 485
> > > > tx_errors: 0
> > > > rx_errors: 0
> > > > rx_missed: 0
> > > > align_errors: 0
> > > > tx_single_collisions: 0
> > > > tx_multi_collisions: 0
> > > > rx_unicast: 18
> > > > rx_broadcast: 295
> > > > rx_multicast: 172
> > > > tx_aborted: 0
> > > > tx_underrun: 0
> > >
> > > So there are received packets at the PC. Not many unicast, mostly
> > > broadcast, which fits with ARP. What does wireshark tell you about
> > > these received packets? Are they ARP replies? Are they something else?
> > > If they are ARP replies, why are they being ignored? I don't know if
> > > tshark will show you CRC problems. Wireshark does, when you unfold a
> > > packet, and look at the fields in detail.
> > >
> > > > Seems like the packet is not being transmitted from the switch at all
> > > > ? (as ping from switch lan4 to PC fails)
> > >
> > > I don't think you can make that conclusion yet. The PC is receiving
> > > something, rx_packets=485. What are those packets?
> > >
> > The received packets captured on the PC are MDNS and DHPC, these MDNS
> > are causing the rx
> > packet counter go up:
>
> And where are these packets coming from? The target device? Or some
> other device on your network?
>
AFIK, MDNS is also kind of a bcast its sending MDNS requests and
receiving itself,
that’s the reason rx packets are incrementing (correct me if I am wrong)
On the PC where lan4 is connected , tx has high count because of ping requests
prabhakar@tango-charlie:~/Desktop/test$ ifconfig enx00e04c68c229
enx00e04c68c229 Link encap:Ethernet HWaddr 00:e0:4c:68:c2:29
inet addr:169.254.78.251 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::2f12:3d45:7cca:57fa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:502 errors:0 dropped:0 overruns:0 frame:0
TX packets:4811 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:79843 (79.8 KB) TX bytes:252647 (252.6 KB)
> > I don’t see any packets reaching the PC for the ping request. I can see the
> > RX and TX on the switch for lan4 increasing every second. seems like the
> > switch itself is consuming it and not forwarding(but then lan4 TX
> > shouldn’t have incremented ?).
>
> Which lan4 counters are going up? tx_packets, rx_packets, tx_errors,
> rx_errors are software counters, and are incremented by the DSA
> core. Other counters are hardware counters, and the DSA driver will
> read them from the actual switch port. If the hardware counters show
> packets are being transmitted, then the packets are probably on the
> cable.
>
I can see the RX and TX incrementing every second, no errors counters go up
$ watch -n1 ifconfig lan4
lan4 Link encap:Ethernet HWaddr C4:F3:12:08:FE:7F
inet addr:169.254.126.126 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::18b9:d16c:7ff:ab73%3201178264/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2168 errors:0 dropped:0 overruns:0 frame:0
TX packets:1724 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:117816 (115.0 KiB) TX bytes:99940 (97.5 KiB)
~$ ethtool -S eth1
NIC statistics:
Good Rx Frames: 800
Broadcast Rx Frames: 729
Multicast Rx Frames: 71
Pause Rx Frames: 0
Rx CRC Errors: 0
Rx Align/Code Errors: 0
Oversize Rx Frames: 0
Rx Jabbers: 0
Undersize (Short) Rx Frames: 0
Rx Fragments: 0
Rx Octets: 65472
Good Tx Frames: 369
Broadcast Tx Frames: 16
Multicast Tx Frames: 139
Pause Tx Frames: 0
Deferred Tx Frames: 0
Collisions: 0
Single Collision Tx Frames: 0
Multiple Collision Tx Frames: 0
Excessive Collisions: 0
Late Collisions: 0
Tx Underrun: 0
Carrier Sense Errors: 0
Tx Octets: 40990
Rx + Tx 64 Octet Frames: 0
Rx + Tx 65-127 Octet Frames: 1031
Rx + Tx 128-255 Octet Frames: 73
Rx + Tx 256-511 Octet Frames: 65
Rx + Tx 512-1023 Octet Frames: 0
Rx + Tx 1024-Up Octet Frames: 0
Net Octets: 106462
Rx Start of Frame Overruns: 0
Rx Middle of Frame Overruns: 0
Rx DMA Overruns: 0
Rx DMA chan 0: head_enqueue: 1
Rx DMA chan 0: tail_enqueue: 918
Rx DMA chan 0: pad_enqueue: 0
Rx DMA chan 0: misqueued: 0
Rx DMA chan 0: desc_alloc_fail: 0
Rx DMA chan 0: pad_alloc_fail: 0
Rx DMA chan 0: runt_receive_buf: 0
Rx DMA chan 0: runt_transmit_bu: 0
Rx DMA chan 0: empty_dequeue: 0
Rx DMA chan 0: busy_dequeue: 772
Rx DMA chan 0: good_dequeue: 791
Rx DMA chan 0: requeue: 0
Rx DMA chan 0: teardown_dequeue: 0
Tx DMA chan 0: head_enqueue: 369
Tx DMA chan 0: tail_enqueue: 0
Tx DMA chan 0: pad_enqueue: 0
Tx DMA chan 0: misqueued: 0
Tx DMA chan 0: desc_alloc_fail: 0
Tx DMA chan 0: pad_alloc_fail: 0
Tx DMA chan 0: runt_receive_buf: 0
Tx DMA chan 0: runt_transmit_bu: 221
Tx DMA chan 0: empty_dequeue: 369
Tx DMA chan 0: busy_dequeue: 0
Tx DMA chan 0: good_dequeue: 369
Tx DMA chan 0: requeue: 0
Tx DMA chan 0: teardown_dequeue: 0
p05_rx_hi: 0
p05_rx_undersize: 0
p05_rx_fragments: 0
p05_rx_oversize: 0
p05_rx_jabbers: 0
p05_rx_symbol_err: 0
p05_rx_crc_err: 0
p05_rx_align_err: 0
p05_rx_mac_ctrl: 0
p05_rx_pause: 0
p05_rx_bcast: 651
p05_rx_mcast: 208
p05_rx_ucast: 214
p05_rx_64_or_less: 593
p05_rx_65_127: 343
p05_rx_128_255: 73
p05_rx_256_511: 64
p05_rx_512_1023: 0
p05_rx_1024_1522: 0
p05_rx_1523_2000: 0
p05_rx_2001: 0
p05_tx_hi: 0
p05_tx_late_col: 0
p05_tx_pause: 0
p05_tx_bcast: 744
p05_tx_mcast: 177
p05_tx_ucast: 0
p05_tx_deferred: 0
p05_tx_total_col: 0
p05_tx_exc_col: 0
p05_tx_single_col: 0
p05_tx_mult_col: 0
p05_rx_total: 99380
p05_tx_total: 86102
p05_rx_discards: 224
p05_tx_discards: 0
~$ ethtool -S lan4
NIC statistics:
tx_packets: 563
tx_bytes: 41522
rx_packets: 1010
rx_bytes: 61155
rx_hi: 0
rx_undersize: 0
rx_fragments: 0
rx_oversize: 0
rx_jabbers: 0
rx_symbol_err: 0
rx_crc_err: 0
rx_align_err: 0
rx_mac_ctrl: 0
rx_pause: 0
rx_bcast: 958
rx_mcast: 222
rx_ucast: 214
rx_64_or_less: 898
rx_65_127: 350
rx_128_255: 80
rx_256_511: 66
rx_512_1023: 0
rx_1024_1522: 0
rx_1523_2000: 0
rx_2001: 0
tx_hi: 0
tx_late_col: 0
tx_pause: 0
tx_bcast: 749
tx_mcast: 212
tx_ucast: 0
tx_deferred: 0
tx_total_col: 0
tx_exc_col: 0
tx_single_col: 0
tx_mult_col: 0
rx_total: 121503
tx_total: 92530
rx_discards: 224
tx_discards: 0
Only weird thing I notice on target, when its replying for ping
requests ( (oui Unknown) is that something which is causing issues ?
08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
VB4-SN00000000 tell tango-charlie.local, length 46
08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply
VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
VB4-SN00000000 tell tango-charlie.local, length 46
08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply
VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
VB4-SN00000000 tell tango-charlie.local, length 46
08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply
VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
Cheers,
--Prabhakar
^ permalink raw reply
* Re: C45 support and mdiobus_scan
From: Jose Abreu @ 2018-08-09 15:07 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180809150309.GA20006@lunn.ch>
Hi Andrew,
Thanks for your answer :)
On 09-08-2018 16:03, Andrew Lunn wrote:
> On Thu, Aug 09, 2018 at 02:54:11PM +0100, Jose Abreu wrote:
>> Hi All,
>>
>> I'm preparing to add support for 10G in stmmac and I noticed that
>> Generic 10G PHY needs C45 support. Digging through the
>> registration callbacks for phy that are used in stmmac I reached
>> to mdiobus_scan() and the following call:
>>
>> phydev = get_phy_device(bus, addr, false);
>>
>> The last parameter is "is_c45", and is always being set to false ...
>>
>> Does this mean that I can't use the Generic 10G PHY in stmmac? I
>> don't mind link being fixed for 10G for now.
> Hi Jose
>
> So far, all MACs which support 10G have used phy-handle to point to a
> PHY on am MDIO bus, and that PHY uses .compatible =
> "ethernet-phy-ieee802.3-c45". of_mdiobus_register() will then find the
> PHY and register it. You really should try to follow this, if you can.
>
>> (Notice I'm using a PCI based setup so no DT bindings can help me
>> for this).
> That is not necessarily true. Take a look at:
>
> arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
>
> &pcie {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_pcie>;
> reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
> status = "okay";
>
> host@0 {
> reg = <0 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
>
> i210: i210@0 {
> reg = <0 0 0 0 0>;
> };
> };
> };
>
> The PCIe core will look in the device tree and when it creates the
> platform device for the i210 on the pcie bus, it points
> pdev->dev.of_node at this node. So long as you are using a platform
> with DT, you can do this. I hope you are not using x86..
Yes I am :( Any possible solution for this?
I guess in ultimate case I will have to switch to ARM based setup.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Andrew
^ permalink raw reply
* Re: [PATCH] iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
From: Kalle Valo @ 2018-08-09 15:14 UTC (permalink / raw)
To: Colin King
Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20180803134224.2609-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> fix spelling mistake in rx stats text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
26b701adc378 iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
--
https://patchwork.kernel.org/patch/10555115/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Andrew Lunn @ 2018-08-09 15:14 UTC (permalink / raw)
To: Anssi Hannula; +Cc: Claudiu Beznea, Nicolas Ferre, David S. Miller, netdev
In-Reply-To: <3c3a606e-b3e1-41fc-fcd8-7b98968fd06b@bitwise.fi>
Hi Anssi
> macb_reset_hw() is called in init path too, though, so maybe clearing
> all bits is intentional / wanted to get the controller to a known state,
> even though the comment only mentions TX/RX?
You need to be careful here. Once of_mdiobus_register() is called, the
MDIO should be usable. If you happen to have an Ethernet switch on the
bus, it could be probed then. The DSA driver will start using the bus.
Or if you have a second PHY, connected to some other MAC, it could be
used by the other MAC. This all happens in the macb_probe function.
Sometime later, the interface will be up'ed. At this point macb_open()
is called, which calls macb_init_hw(), which calls
macb_reset_hw(). What you don't want happening is changes to the NCR
at this point breaking an MDIO transaction which might be going on.
Ideally, the MPE should be enabled before of_mdiobus_register(), and
left alone until mdiobus_unregister() is called in macb_remove().
Andrew
^ permalink raw reply
* [PATCH iproute2/net-next] tc_util: Add support for showing TCA_STATS_BASIC_HW statistics
From: Eelco Chaudron @ 2018-08-09 15:16 UTC (permalink / raw)
To: netdev; +Cc: davem, stephen
Add support for showing hardware specific counters to easily
troubleshoot hardware offload.
$ tc -s filter show dev enp3s0np0 parent ffff:
filter protocol ip pref 1 flower chain 0
filter protocol ip pref 1 flower chain 0 handle 0x1
eth_type ipv4
dst_ip 2.0.0.0
src_ip 1.0.0.0
ip_flags nofrag
in_hw
action order 1: mirred (Egress Redirect to device eth1) stolen
index 1 ref 1 bind 1 installed 0 sec used 0 sec
Action statistics:
Sent 534884742 bytes 8915697 pkt (dropped 0, overlimits 0 requeues 0)
Sent software 187542 bytes 4077 pkt
Sent hardware 534697200 bytes 8911620 pkt
backlog 0b 0p requeues 0
cookie 89173e6a44447001becfd486bda17e29
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
---
include/uapi/linux/gen_stats.h | 1 +
tc/tc_util.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/uapi/linux/gen_stats.h b/include/uapi/linux/gen_stats.h
index 24a861c..065408e 100644
--- a/include/uapi/linux/gen_stats.h
+++ b/include/uapi/linux/gen_stats.h
@@ -12,6 +12,7 @@ enum {
TCA_STATS_APP,
TCA_STATS_RATE_EST64,
TCA_STATS_PAD,
+ TCA_STATS_BASIC_HW,
__TCA_STATS_MAX,
};
#define TCA_STATS_MAX (__TCA_STATS_MAX - 1)
diff --git a/tc/tc_util.c b/tc/tc_util.c
index d757852..43a2013 100644
--- a/tc/tc_util.c
+++ b/tc/tc_util.c
@@ -800,6 +800,41 @@ void print_tm(FILE *f, const struct tcf_t *tm)
}
}
+static void print_tcstats_basic_hw(struct rtattr **tbs, char *prefix)
+{
+ struct gnet_stats_basic bs = {0};
+ struct gnet_stats_basic bs_hw = {0};
+
+ if (!tbs[TCA_STATS_BASIC_HW])
+ return;
+
+ memcpy(&bs_hw, RTA_DATA(tbs[TCA_STATS_BASIC_HW]),
+ MIN(RTA_PAYLOAD(tbs[TCA_STATS_BASIC_HW]), sizeof(bs_hw)));
+
+ if (bs_hw.bytes == 0 && bs_hw.packets == 0)
+ return;
+
+ if (tbs[TCA_STATS_BASIC]) {
+ memcpy(&bs, RTA_DATA(tbs[TCA_STATS_BASIC]),
+ MIN(RTA_PAYLOAD(tbs[TCA_STATS_BASIC]),
+ sizeof(bs)));
+ }
+
+ if (bs.bytes >= bs_hw.bytes && bs.packets >= bs_hw.packets) {
+ print_string(PRINT_FP, NULL, "\n%s", prefix);
+ print_lluint(PRINT_ANY, "sw_bytes",
+ "Sent software %llu bytes",
+ bs.bytes - bs_hw.bytes);
+ print_uint(PRINT_ANY, "sw_packets", " %u pkt",
+ bs.packets - bs_hw.packets);
+ }
+
+ print_string(PRINT_FP, NULL, "\n%s", prefix);
+ print_lluint(PRINT_ANY, "hw_bytes", "Sent hardware %llu bytes",
+ bs_hw.bytes);
+ print_uint(PRINT_ANY, "hw_packets", " %u pkt", bs_hw.packets);
+}
+
void print_tcstats2_attr(FILE *fp, struct rtattr *rta, char *prefix, struct rtattr **xstats)
{
SPRINT_BUF(b1);
@@ -826,6 +861,9 @@ void print_tcstats2_attr(FILE *fp, struct rtattr *rta, char *prefix, struct rtat
print_uint(PRINT_ANY, "requeues", " requeues %u) ", q.requeues);
}
+ if (tbs[TCA_STATS_BASIC_HW])
+ print_tcstats_basic_hw(tbs, prefix);
+
if (tbs[TCA_STATS_RATE_EST64]) {
struct gnet_stats_rate_est64 re = {0};
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix bpffs non-array map seq_show issue
From: Yonghong Song @ 2018-08-09 15:15 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: ast, netdev, kernel-team
In-Reply-To: <c8c3b728-adf7-77d8-70a9-f6c9684e771d@iogearbox.net>
On 8/9/18 7:24 AM, Daniel Borkmann wrote:
> On 08/09/2018 05:55 AM, Yonghong Song wrote:
>> On 8/8/18 7:25 PM, Alexei Starovoitov wrote:
>>> On Wed, Aug 08, 2018 at 06:25:19PM -0700, Yonghong Song wrote:
>>>> In function map_seq_next() of kernel/bpf/inode.c,
>>>> the first key will be the "0" regardless of the map type.
>>>> This works for array. But for hash type, if it happens
>>>> key "0" is in the map, the bpffs map show will miss
>>>> some items if the key "0" is not the first element of
>>>> the first bucket.
>>>>
>>>> This patch fixed the issue by guaranteeing to get
>>>> the first element, if the seq_show is just started,
>>>> by passing NULL pointer key to map_get_next_key() callback.
>>>> This way, no missing elements will occur for
>>>> bpffs hash table show even if key "0" is in the map.
>>
>> Currently, map_seq_show_elem callback is only implemented
>> for arraymap. So the problem actually is not exposed.
>>
>> The issue is discovered when I tried to implement
>> map_seq_show_elem for hash maps, and I will have followup
>> patches for it.
>>
>> So this patch probably should apply to bpf-next or
>> I can include this patch in my later patch set
>> which implements map_seq_show_elem for hash map
>> which can demonstrate the problem.
>>
>> Please let me know.
>>
>>>> Fixes: a26ca7c982cb5 ("bpf: btf: Add pretty print support to the basic arraymap")
>>>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>>
>>> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
> Given this doesn't affect any current code, I think bpf-next
> would be fine.
>
> Anyway, this cannot be used as-is, results in following compile
> warning ...
Thanks and will fix the problem and resubmit the patch set to
bpf-next.
>
> # make -j4 kernel/bpf/
> DESCEND objtool
> CALL scripts/checksyscalls.sh
> CC kernel/bpf/verifier.o
> CC kernel/bpf/inode.o
> kernel/bpf/inode.c: In function ‘map_seq_next’:
> kernel/bpf/inode.c:214:1: warning: label ‘done’ defined but not used [-Wunused-label]
> done:
> ^~~~
> AR kernel/bpf/built-in.a
>
^ permalink raw reply
* Re: C45 support and mdiobus_scan
From: Andrew Lunn @ 2018-08-09 15:25 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org
In-Reply-To: <568ff5ce-02ac-40f9-ccf7-fa00fb9c6b2a@synopsys.com>
> > The PCIe core will look in the device tree and when it creates the
> > platform device for the i210 on the pcie bus, it points
> > pdev->dev.of_node at this node. So long as you are using a platform
> > with DT, you can do this. I hope you are not using x86..
>
> Yes I am :( Any possible solution for this?
Well, DT can be used with x86. I think Edison did that. But i assume
your PCIe host is in ACPI, not DT. So getting this linking working
will not be easy.
There has been some work to add an ACPI binding for PHYs. I don't know
if it actually got far enough that you can hack your DSDT to add a
PHY. But i'm sure it did not get far enough that you can describe an
MDIO bus in DSDT, so it probably is not going to help you.
> I guess in ultimate case I will have to switch to ARM based setup.
Yes, or MIPS.
Andrew
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Andrew Lunn @ 2018-08-09 15:35 UTC (permalink / raw)
To: Lad, Prabhakar; +Cc: netdev
In-Reply-To: <CA+V-a8sEKfe+vRkxM7EKwH9h3HwLcW_k1Ygso2K3h5jY3TtaiA@mail.gmail.com>
> > > The received packets captured on the PC are MDNS and DHPC, these MDNS
> > > are causing the rx
> > > packet counter go up:
> >
> > And where are these packets coming from? The target device? Or some
> > other device on your network?
> >
> AFIK, MDNS is also kind of a bcast its sending MDNS requests and
> receiving itself,
> that’s the reason rx packets are incrementing (correct me if I am wrong)
Your Ethernet device should not be receiving its own
transmissions. Looping back for broadcast and multicast packets
happens higher up in the network stack.
Look at the source MAC address for these packets. Where are the coming
from?
> ~$ ethtool -S lan4
> NIC statistics:
...
> tx_hi: 0
> tx_late_col: 0
> tx_pause: 0
> tx_bcast: 749
> tx_mcast: 212
This suggest the switch is putting packets onto the wire.
> Only weird thing I notice on target, when its replying for ping
> requests ( (oui Unknown) is that something which is causing issues ?
These are not ping requests. These are ARP requests/replies.
> 08:11:20.230704 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:20.230749 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> 08:11:21.230629 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:21.230657 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
> 08:11:22.247831 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
> VB4-SN00000000 tell tango-charlie.local, length 46
> 08:11:22.247857 ARP, Ethernet (len 6), IPv4 (len 4), Reply
> VB4-SN00000000 is-at c4:f3:12:08:fe:7f (oui Unknown), length 28
c4:f3:12 is the OUI. It is actually registers to TI:
https://aruljohn.com/mac/C4F312
But tcpdump probably does not know this, or the build you have has the
oui table removed to keep the binary small.
Andrew
^ permalink raw reply
* Re: [net-next, PATCH 1/2] net: socionext: Use descriptor info instead of MMIO reads on Rx
From: Arnd Bergmann @ 2018-08-09 15:37 UTC (permalink / raw)
To: Ilias Apalodimas; +Cc: Networking, Jassi Brar
In-Reply-To: <1533801739-15312-1-git-send-email-ilias.apalodimas@linaro.org>
On Thu, Aug 9, 2018 at 10:02 AM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> MMIO reads for remaining packets in queue occur (at least)twice per
> invocation of netsec_process_rx(). We can use the packet descriptor to
> identify if it's owned by the hardware and break out, avoiding the more
> expensive MMIO read operations. This has a ~2% increase on the pps of the
> Rx path when tested with 64byte packets
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
> drivers/net/ethernet/socionext/netsec.c | 19 +++++--------------
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
> index 01589b6..ae32909 100644
> --- a/drivers/net/ethernet/socionext/netsec.c
> +++ b/drivers/net/ethernet/socionext/netsec.c
> @@ -657,8 +657,6 @@ static struct sk_buff *netsec_get_rx_pkt_data(struct netsec_priv *priv,
> + if (de->attr & (1U << NETSEC_RX_PKT_OWN_FIELD))
> + break;
> done++;
Should this use READ_ONCE() to prevent the compiler from moving the
access around? I see that netsec_get_rx_pkt_data() has a dma_rmb()
before reading the data, which prevents the CPU from doing something
wrong here, but not the compiler.
Arnd
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: Andy Lutomirski @ 2018-08-09 18:08 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Ingo Molnar, Thomas Gleixner, linux-arch, Eric Biggers,
Linux Crypto Mailing List, LKML, Netdev, David Miller,
Andrew Lutomirski, Greg Kroah-Hartman, Samuel Neves,
Daniel J . Bernstein, Tanja Lange, Jean-Philippe Aumasson,
Karthikeyan Bhargavan
In-Reply-To: <CAHmME9rG8VFfuuCy=rCVmxb1CdneYGv1d4xmsyqSPooBozoOJw@mail.gmail.com>
On Tue, Aug 7, 2018 at 6:51 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Tue, Aug 7, 2018 at 6:49 PM Andy Lutomirski <luto@amacapital.net> wrote:
>> I really wish we had a way to see that we use asm-generic’s copy of a header in all cases except where an arch opts out.
>
> It's really not that hard to do -- symlink asm-generic to a target
> called "asm" inside an otherwise empty directory, and add that
> otherwise empty directory to the -I paths just after arch/include.
> Since it's searched second, it's only used if the first fails. Maybe
> I'm missing something though, as this seems a bit too obvious. Perhaps
> a project for another day.
The problem here (I think) is that it's preferable for stray files in
the kernel tree to have no effect and, with this scheme, stray files
in arch/*/include/asm could affect the build. So something explicit
has an advantage. I just think there should be way to say "this
asm-generic file should affect all arches unless they generic-n or
override-generic-y it or whatever".
^ permalink raw reply
* [PATCH bpf-next 2/3] bpf: btf: add pretty print for hash/lru_hash maps
From: Yonghong Song @ 2018-08-09 15:55 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180809155521.1544888-1-yhs@fb.com>
Commit a26ca7c982cb ("bpf: btf: Add pretty print support to
the basic arraymap") added pretty print support to array map.
This patch adds pretty print for hash and lru_hash maps.
The following example shows the pretty-print result of
a pinned hashmap:
struct map_value {
int count_a;
int count_b;
};
cat /sys/fs/bpf/pinned_hash_map:
87907: {87907,87908}
57354: {37354,57355}
76625: {76625,76626}
...
Signed-off-by: Yonghong Song <yhs@fb.com>
---
kernel/bpf/hashtab.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 513d9dfcf4ee..d6110042e0d9 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -11,9 +11,11 @@
* General Public License for more details.
*/
#include <linux/bpf.h>
+#include <linux/btf.h>
#include <linux/jhash.h>
#include <linux/filter.h>
#include <linux/rculist_nulls.h>
+#include <uapi/linux/btf.h>
#include "percpu_freelist.h"
#include "bpf_lru_list.h"
#include "map_in_map.h"
@@ -1162,6 +1164,44 @@ static void htab_map_free(struct bpf_map *map)
kfree(htab);
}
+static void htab_map_seq_show_elem(struct bpf_map *map, void *key,
+ struct seq_file *m)
+{
+ void *value;
+
+ rcu_read_lock();
+
+ value = htab_map_lookup_elem(map, key);
+ if (!value) {
+ rcu_read_unlock();
+ return;
+ }
+
+ btf_type_seq_show(map->btf, map->btf_key_type_id, key, m);
+ seq_puts(m, ": ");
+ btf_type_seq_show(map->btf, map->btf_value_type_id, value, m);
+ seq_puts(m, "\n");
+
+ rcu_read_unlock();
+}
+
+static int htab_map_check_btf(const struct bpf_map *map, const struct btf *btf,
+ u32 btf_key_id, u32 btf_value_id)
+{
+ const struct btf_type *key_type, *value_type;
+ u32 key_size, value_size;
+
+ key_type = btf_type_id_size(btf, &btf_key_id, &key_size);
+ if (!key_type || key_size != map->key_size)
+ return -EINVAL;
+
+ value_type = btf_type_id_size(btf, &btf_value_id, &value_size);
+ if (!value_type || value_size != map->value_size)
+ return -EINVAL;
+
+ return 0;
+}
+
const struct bpf_map_ops htab_map_ops = {
.map_alloc_check = htab_map_alloc_check,
.map_alloc = htab_map_alloc,
@@ -1171,6 +1211,8 @@ const struct bpf_map_ops htab_map_ops = {
.map_update_elem = htab_map_update_elem,
.map_delete_elem = htab_map_delete_elem,
.map_gen_lookup = htab_map_gen_lookup,
+ .map_seq_show_elem = htab_map_seq_show_elem,
+ .map_check_btf = htab_map_check_btf,
};
const struct bpf_map_ops htab_lru_map_ops = {
@@ -1182,6 +1224,8 @@ const struct bpf_map_ops htab_lru_map_ops = {
.map_update_elem = htab_lru_map_update_elem,
.map_delete_elem = htab_lru_map_delete_elem,
.map_gen_lookup = htab_lru_map_gen_lookup,
+ .map_seq_show_elem = htab_map_seq_show_elem,
+ .map_check_btf = htab_map_check_btf,
};
/* Called from eBPF program */
--
2.14.3
^ permalink raw reply related
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