Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-20 Thread Florian Fainelli 
On March 17, 2016 1:10:31 PM PDT, Murali Karicheri  wrote:
>David,
>
>On 08/18/2015 04:47 PM, David Miller wrote:
>> I see some drivers where the foo_debugfs.c file is larger than the
>rest
>> of the driver.  Once people start using it, it's like crack, and they
>> dump every single debugging widget they found useful at some point
>into
>> there.
>> 
>> This is not what we want.  Most things I see in debugfs support was
>> probably useful for debugging one particular bug but then it was
>never
>> really useful again in the future.  Those kinds of things can be done
>> locally in someone's tree.
>> 
>> I often see various kinds of "statistics" ending up in these things,
>> or register dumps, both of which are 'ethtool' or similar material.
>Very late to this discussion, but I need to port some of the internal
>code
>to display the content of a ALE (Address Learning Engine) table
>maintained
>in hardwareat L2 layer. Currently I have a sysfs implementation that
>dumps
>information like below.
>
>root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>index 0, raw: 07fc d000 , type: addr(1), addr:
>ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>index 1, raw:  1800 28329a1c, type: addr(1), addr:
>08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>index 2, raw: 07fc d100 5e01, type: addr(1), addr:
>01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr:
>d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>
>What is the available interface in kernel to expose this information
>to user space as debugfs is not suggested based on this thread

Using something like bridge fdb show (bridge sub command part of iproute2) 
would give you most of what you need here, except the port mask (since that is 
semi implied by which interface you use for dumping) and internal flags about 
the address validity.

How frequently is this code used once you have a proper switch driver which 
supports the FDB add/del/dump operations?


-- 
Florian

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-19 Thread Murali Karicheri 
On 03/17/2016 07:18 PM, Florian Fainelli wrote:
> On 17/03/16 13:48, Murali Karicheri wrote:
>> On 03/17/2016 04:25 PM, Andrew Lunn wrote:
>>> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
 David,

 On 08/18/2015 04:47 PM, David Miller wrote:
> I see some drivers where the foo_debugfs.c file is larger than the rest
> of the driver.  Once people start using it, it's like crack, and they
> dump every single debugging widget they found useful at some point into
> there.
>
> This is not what we want.  Most things I see in debugfs support was
> probably useful for debugging one particular bug but then it was never
> really useful again in the future.  Those kinds of things can be done
> locally in someone's tree.
>
> I often see various kinds of "statistics" ending up in these things,
> or register dumps, both of which are 'ethtool' or similar material.
 Very late to this discussion, but I need to port some of the internal code
 to display the content of a ALE (Address Learning Engine) table maintained
 in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
 information like below.

 root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
 index 0, raw: 07fc d000 , type: addr(1), addr: 
 ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
 index 1, raw:  1800 28329a1c, type: addr(1), addr: 
 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
 index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
 index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
 d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1

 What is the available interface in kernel to expose this information
 to user space as debugfs is not suggested based on this thread?
>>>
>>> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>>> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>>> switchdev_port_obj_dump() in the switchdev ops.
>>>
>> Andrew,
>>
>> Which tool user has to use to get this dump once implemented?
> 
> iproute2's bridge command with bridge fdb show .
> 
Thanks

-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-19 Thread Andrew Lunn 
On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
> David,
> 
> On 08/18/2015 04:47 PM, David Miller wrote:
> > I see some drivers where the foo_debugfs.c file is larger than the rest
> > of the driver.  Once people start using it, it's like crack, and they
> > dump every single debugging widget they found useful at some point into
> > there.
> > 
> > This is not what we want.  Most things I see in debugfs support was
> > probably useful for debugging one particular bug but then it was never
> > really useful again in the future.  Those kinds of things can be done
> > locally in someone's tree.
> > 
> > I often see various kinds of "statistics" ending up in these things,
> > or register dumps, both of which are 'ethtool' or similar material.
> Very late to this discussion, but I need to port some of the internal code
> to display the content of a ALE (Address Learning Engine) table maintained
> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
> information like below.
> 
> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
> index 0, raw: 07fc d000 , type: addr(1), addr: 
> ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
> index 1, raw:  1800 28329a1c, type: addr(1), addr: 
> 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
> index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
> 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
> index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
> d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
> 
> What is the available interface in kernel to expose this information
> to user space as debugfs is not suggested based on this thread?

This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
switchdev_port_obj_dump() in the switchdev ops.

  Andrew

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-19 Thread Florian Fainelli 
On 17/03/16 13:48, Murali Karicheri wrote:
> On 03/17/2016 04:25 PM, Andrew Lunn wrote:
>> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>>> David,
>>>
>>> On 08/18/2015 04:47 PM, David Miller wrote:
 I see some drivers where the foo_debugfs.c file is larger than the rest
 of the driver.  Once people start using it, it's like crack, and they
 dump every single debugging widget they found useful at some point into
 there.

 This is not what we want.  Most things I see in debugfs support was
 probably useful for debugging one particular bug but then it was never
 really useful again in the future.  Those kinds of things can be done
 locally in someone's tree.

 I often see various kinds of "statistics" ending up in these things,
 or register dumps, both of which are 'ethtool' or similar material.
>>> Very late to this discussion, but I need to port some of the internal code
>>> to display the content of a ALE (Address Learning Engine) table maintained
>>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>>> information like below.
>>>
>>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>>> index 0, raw: 07fc d000 , type: addr(1), addr: 
>>> ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>>> index 1, raw:  1800 28329a1c, type: addr(1), addr: 
>>> 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>>> index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
>>> 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>>> index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
>>> d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>>
>>> What is the available interface in kernel to expose this information
>>> to user space as debugfs is not suggested based on this thread?
>>
>> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>> switchdev_port_obj_dump() in the switchdev ops.
>>
> Andrew,
> 
> Which tool user has to use to get this dump once implemented?

iproute2's bridge command with bridge fdb show .
-- 
Florian

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-19 Thread Murali Karicheri 
On 03/17/2016 04:25 PM, Andrew Lunn wrote:
> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>> David,
>>
>> On 08/18/2015 04:47 PM, David Miller wrote:
>>> I see some drivers where the foo_debugfs.c file is larger than the rest
>>> of the driver.  Once people start using it, it's like crack, and they
>>> dump every single debugging widget they found useful at some point into
>>> there.
>>>
>>> This is not what we want.  Most things I see in debugfs support was
>>> probably useful for debugging one particular bug but then it was never
>>> really useful again in the future.  Those kinds of things can be done
>>> locally in someone's tree.
>>>
>>> I often see various kinds of "statistics" ending up in these things,
>>> or register dumps, both of which are 'ethtool' or similar material.
>> Very late to this discussion, but I need to port some of the internal code
>> to display the content of a ALE (Address Learning Engine) table maintained
>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>> information like below.
>>
>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>> index 0, raw: 07fc d000 , type: addr(1), addr: 
>> ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>> index 1, raw:  1800 28329a1c, type: addr(1), addr: 
>> 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>> index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
>> 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>> index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
>> d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>
>> What is the available interface in kernel to expose this information
>> to user space as debugfs is not suggested based on this thread?
> 
> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
> switchdev_port_obj_dump() in the switchdev ops.
> 
Andrew,

Which tool user has to use to get this dump once implemented?

Murali

> Andrew
> 


-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-19 Thread Ido Schimmel 
Thu, Mar 17, 2016 at 10:25:19PM IST, and...@lunn.ch wrote:
>On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>> David,
>> 
>> On 08/18/2015 04:47 PM, David Miller wrote:
>> > I see some drivers where the foo_debugfs.c file is larger than the rest
>> > of the driver.  Once people start using it, it's like crack, and they
>> > dump every single debugging widget they found useful at some point into
>> > there.
>> > 
>> > This is not what we want.  Most things I see in debugfs support was
>> > probably useful for debugging one particular bug but then it was never
>> > really useful again in the future.  Those kinds of things can be done
>> > locally in someone's tree.
>> > 
>> > I often see various kinds of "statistics" ending up in these things,
>> > or register dumps, both of which are 'ethtool' or similar material.
>> Very late to this discussion, but I need to port some of the internal code
>> to display the content of a ALE (Address Learning Engine) table maintained
>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>> information like below.
>> 
>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>> index 0, raw: 07fc d000 , type: addr(1), addr: 
>> ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>> index 1, raw:  1800 28329a1c, type: addr(1), addr: 
>> 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>> index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
>> 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>> index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
>> d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>> 
>> What is the available interface in kernel to expose this information
>> to user space as debugfs is not suggested based on this thread?
>
>This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>switchdev_port_obj_dump() in the switchdev ops.

+1

Also, Murali, using standard interfaces instead of debugfs will allow
you to:

1) Upstream your code
2) Use existing tests for your code. In particular, the following
(which is used for mlxsw testing):

https://github.com/jpirko/lnst/blob/master/recipes/switchdev/l2-002-bridge_fdb.py

There are a bunch of others there which you'll probably find useful.

BTW, are you familiar with the following document?
https://www.kernel.org/doc/Documentation/networking/switchdev.txt
I believe it answers your question.

Good luck!

>
> Andrew

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-18 Thread Murali Karicheri 
David,

On 08/18/2015 04:47 PM, David Miller wrote:
> I see some drivers where the foo_debugfs.c file is larger than the rest
> of the driver.  Once people start using it, it's like crack, and they
> dump every single debugging widget they found useful at some point into
> there.
> 
> This is not what we want.  Most things I see in debugfs support was
> probably useful for debugging one particular bug but then it was never
> really useful again in the future.  Those kinds of things can be done
> locally in someone's tree.
> 
> I often see various kinds of "statistics" ending up in these things,
> or register dumps, both of which are 'ethtool' or similar material.
Very late to this discussion, but I need to port some of the internal code
to display the content of a ALE (Address Learning Engine) table maintained
in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
information like below.

root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
index 0, raw: 07fc d000 , type: addr(1), addr: 
ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
index 1, raw:  1800 28329a1c, type: addr(1), addr: 
08:00:28:32:9a:1c, uctype: persistent(0), port: 0
index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1

What is the available interface in kernel to expose this information
to user space as debugfs is not suggested based on this thread?

-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2016-03-18 Thread Murali Karicheri 
On 03/17/2016 05:53 PM, Ido Schimmel wrote:
> Thu, Mar 17, 2016 at 10:25:19PM IST, and...@lunn.ch wrote:
>> On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote:
>>> David,
>>>
>>> On 08/18/2015 04:47 PM, David Miller wrote:
 I see some drivers where the foo_debugfs.c file is larger than the rest
 of the driver.  Once people start using it, it's like crack, and they
 dump every single debugging widget they found useful at some point into
 there.

 This is not what we want.  Most things I see in debugfs support was
 probably useful for debugging one particular bug but then it was never
 really useful again in the future.  Those kinds of things can be done
 locally in someone's tree.

 I often see various kinds of "statistics" ending up in these things,
 or register dumps, both of which are 'ethtool' or similar material.
>>> Very late to this discussion, but I need to port some of the internal code
>>> to display the content of a ALE (Address Learning Engine) table maintained
>>> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps
>>> information like below.
>>>
>>> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table
>>> index 0, raw: 07fc d000 , type: addr(1), addr: 
>>> ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super
>>> index 1, raw:  1800 28329a1c, type: addr(1), addr: 
>>> 08:00:28:32:9a:1c, uctype: persistent(0), port: 0
>>> index 2, raw: 07fc d100 5e01, type: addr(1), addr: 
>>> 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super
>>> index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: 
>>> d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1
>>>
>>> What is the available interface in kernel to expose this information
>>> to user space as debugfs is not suggested based on this thread?
>>
>> This looks a lot like what the mv88e6xxx_port_fdb_dump() callback
>> returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to
>> switchdev_port_obj_dump() in the switchdev ops.
> 
> +1
> 
> Also, Murali, using standard interfaces instead of debugfs will allow
> you to:
> 
> 1) Upstream your code
> 2) Use existing tests for your code. In particular, the following
> (which is used for mlxsw testing):
> 
> https://github.com/jpirko/lnst/blob/master/recipes/switchdev/l2-002-bridge_fdb.py
> 
> There are a bunch of others there which you'll probably find useful.
> 
> BTW, are you familiar with the following document?
> https://www.kernel.org/doc/Documentation/networking/switchdev.txt
> I believe it answers your question.

Yes. I have support for DSA and switchdev for netcp driver in my TODO list.
Will post more questions on this once I start work on this.

Thanks

Murali
> 
> Good luck!
> 
>>
>>Andrew
> 


-- 
Murali Karicheri
Linux Kernel, Keystone

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-19 Thread Scott Feldman 
On Tue, Aug 18, 2015 at 1:47 PM, David Miller da...@davemloft.net wrote:
 From: Scott Feldman sfel...@gmail.com
 Date: Tue, 18 Aug 2015 13:37:56 -0700


  Hi Scott
 
  David is not so keen no debugfs stuff. He already NACKed adding more
  than what is currently in DSA:
 
  https://lkml.org/lkml/2015/7/11/8

 That patch added writable debugfs files, which I can see might be used
 as a back-door to program hardware.  That does seem bad.

 I fully agreed with respect to write. But if you read the whole
 message, David is also not happy with read only.

 I think before you spend too much more time on this, you need some
 indication from David if he is going to merge it or not.

 David, please give us guidance on debugfs in drivers/net.  Is there
 some criteria we can define to know when it's OK to use debugfs?

 The less you use it the better, seriously.

 I see some drivers where the foo_debugfs.c file is larger than the rest
 of the driver.  Once people start using it, it's like crack, and they
 dump every single debugging widget they found useful at some point into
 there.

 This is not what we want.  Most things I see in debugfs support was
 probably useful for debugging one particular bug but then it was never
 really useful again in the future.  Those kinds of things can be done
 locally in someone's tree.

 I often see various kinds of statistics ending up in these things,
 or register dumps, both of which are 'ethtool' or similar material.

# git grep debugfs_create drivers/net

^^^  this is scary.  I see some crazy things being done here.   The
writable nodes look like workaround driver/device bugs or to provide
backdoor interfaces that don't exist natively.

I say we clean up this mess.  Just eliminating the writable files
would force bugs to get fixed and get new interfaces defined.  And
replace readable files when interface exist (stats/reg).  Finally,
look for readable files that can be converted to new shared common
interfaces.  What's left should be read-only (S_IRUGO) files (no
binary blobs) containing data unique for driver/device useful for
field troubleshooting.

I'm motivated.  Next net-next cycle I'm going to go down the list with
a big eraser.  I'm sure I'll be a popular guy.

-scott
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Scott Feldman 
On Mon, Aug 17, 2015 at 10:55 PM, Jiri Pirko j...@resnulli.us wrote:
 Tue, Aug 18, 2015 at 12:36:17AM CEST, sfel...@gmail.com wrote:
From: Scott Feldman sfel...@gmail.com

 tree /sys/kernel/debug/rocker
/sys/kernel/debug/rocker
└── 525400123501
├── fdb_tbl
├── internal_vlan_tbl
├── neigh_tbl
├── of_dpa_flow_tbl
└── of_dpa_group_tbl

1 directory, 5 files

 cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
ifindex 5 ref_count 1 vlan 3843
ifindex 7 ref_count 2 vlan 3840
ifindex 4 ref_count 1 vlan 3842

 cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840

 cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1

 cat /sys/kernel/debug/rocker/525400123501/of_dpa_flow_tbl
cmd 3 cookie 15 priority 3  tbl aclin_pport 2 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3841 ip proto 0/0 
ip tos 0/0 group_id 0x0f01
cmd 3 cookie 2  priority 0  tbl term_mac   in_pport 1 eth_type 0x0800 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie 1f priority 3  tbl bridge 00:02:00:00:00:00 vlan_id 3840 
tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 4  priority 1  tbl vlan   in_pport 2 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3841
cmd 3 cookie 20 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.1 
goto_tbl acl group_id 0x2000
cmd 3 cookie 21 priority 3  tbl bridge 00:02:00:00:01:00 vlan_id 3841 
tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 16 priority 2  tbl aclin_pport 2 eth_type 0x0806 
vlan_id 3841 ip proto 0/0 ip tos 0/0 group_id 0x0f01
cmd 3 cookie 12 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.0 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 9  priority 3  tbl aclin_pport 1 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3840 ip proto 0/0 
ip tos 0/0 group_id 0x0f00
cmd 3 cookie 6  priority 0  tbl term_mac   in_pport 2 eth_type 0x86dd 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 4 cookie 0  priority 1  tbl ig_portin_pport 0/0x goto_tbl 
vlan
cmd 4 cookie e  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.3 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 1  priority 1  tbl vlan   in_pport 1 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3840
cmd 3 cookie 24 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.4/255.255.255.252 goto_tbl acl group_id 0x2000
cmd 4 cookie 14 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.10 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 2c priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.4 
goto_tbl acl group_id 0x2001
cmd 3 cookie 17 priority 1  tbl term_mac   in_pport 2 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 26 priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.3 
goto_tbl acl group_id 0x2000
cmd 3 cookie 2e priority 30 tbl ucast_routing  eth_type 0x0800 12.0.0.2 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 22 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.9 
goto_tbl acl group_id 0x2001
cmd 3 cookie 1c priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.8/255.255.255.252 goto_tbl acl group_id 0x0f01
cmd 3 cookie 18 priority 1  tbl term_mac   in_pport 2 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 5  priority 0  tbl term_mac   in_pport 2 eth_type 0x0800 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie a  priority 2  tbl aclin_pport 1 eth_type 0x0806 
vlan_id 3840 ip proto 0/0 ip tos 0/0 group_id 0x0f00
cmd 4 cookie 1a priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.11 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 1e priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.8 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 3  priority 0  tbl term_mac   in_pport 1 eth_type 0x86dd 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie b  priority 1  tbl term_mac   in_pport 1 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3840 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 4 cookie 8  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.2 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 10 priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.0/255.255.255.252 goto_tbl acl group_id 0x0f00
cmd 3 cookie 28 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.12/255.255.255.252 goto_tbl acl group_id 0x2001
cmd 3 cookie c  priority 1  tbl term_mac   in_pport 1 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3840

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Jiri Pirko 
Tue, Aug 18, 2015 at 08:14:48AM CEST, sfel...@gmail.com wrote:
On Mon, Aug 17, 2015 at 10:55 PM, Jiri Pirko j...@resnulli.us wrote:
 Tue, Aug 18, 2015 at 12:36:17AM CEST, sfel...@gmail.com wrote:
From: Scott Feldman sfel...@gmail.com

 tree /sys/kernel/debug/rocker
/sys/kernel/debug/rocker
└── 525400123501
├── fdb_tbl
├── internal_vlan_tbl
├── neigh_tbl
├── of_dpa_flow_tbl
└── of_dpa_group_tbl

1 directory, 5 files

 cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
ifindex 5 ref_count 1 vlan 3843
ifindex 7 ref_count 2 vlan 3840
ifindex 4 ref_count 1 vlan 3842

 cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840

 cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1

 cat /sys/kernel/debug/rocker/525400123501/of_dpa_flow_tbl
cmd 3 cookie 15 priority 3  tbl aclin_pport 2 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3841 ip proto 
0/0 ip tos 0/0 group_id 0x0f01
cmd 3 cookie 2  priority 0  tbl term_mac   in_pport 1 eth_type 0x0800 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie 1f priority 3  tbl bridge 00:02:00:00:00:00 vlan_id 
3840 tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 4  priority 1  tbl vlan   in_pport 2 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3841
cmd 3 cookie 20 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.1 
goto_tbl acl group_id 0x2000
cmd 3 cookie 21 priority 3  tbl bridge 00:02:00:00:01:00 vlan_id 
3841 tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 16 priority 2  tbl aclin_pport 2 eth_type 0x0806 
vlan_id 3841 ip proto 0/0 ip tos 0/0 group_id 0x0f01
cmd 3 cookie 12 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.0 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 9  priority 3  tbl aclin_pport 1 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3840 ip proto 
0/0 ip tos 0/0 group_id 0x0f00
cmd 3 cookie 6  priority 0  tbl term_mac   in_pport 2 eth_type 0x86dd 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 4 cookie 0  priority 1  tbl ig_portin_pport 0/0x 
goto_tbl vlan
cmd 4 cookie e  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.3 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 1  priority 1  tbl vlan   in_pport 1 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3840
cmd 3 cookie 24 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.4/255.255.255.252 goto_tbl acl group_id 0x2000
cmd 4 cookie 14 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.10 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 2c priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.4 
goto_tbl acl group_id 0x2001
cmd 3 cookie 17 priority 1  tbl term_mac   in_pport 2 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 26 priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.3 
goto_tbl acl group_id 0x2000
cmd 3 cookie 2e priority 30 tbl ucast_routing  eth_type 0x0800 12.0.0.2 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 22 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.9 
goto_tbl acl group_id 0x2001
cmd 3 cookie 1c priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.8/255.255.255.252 goto_tbl acl group_id 0x0f01
cmd 3 cookie 18 priority 1  tbl term_mac   in_pport 2 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 5  priority 0  tbl term_mac   in_pport 2 eth_type 0x0800 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie a  priority 2  tbl aclin_pport 1 eth_type 0x0806 
vlan_id 3840 ip proto 0/0 ip tos 0/0 group_id 0x0f00
cmd 4 cookie 1a priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.11 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 1e priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.8 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 3  priority 0  tbl term_mac   in_pport 1 eth_type 0x86dd 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie b  priority 1  tbl term_mac   in_pport 1 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3840 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 4 cookie 8  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.2 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 10 priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.0/255.255.255.252 goto_tbl acl group_id 0x0f00
cmd 3 cookie 28 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.12/255.255.255.252 goto_tbl acl group_id 0x2001
cmd 3 cookie c  priority 1  tbl term_mac   in_pport 1

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Scott Feldman 
On Mon, Aug 17, 2015 at 11:48 PM, Jiri Pirko j...@resnulli.us wrote:
 Tue, Aug 18, 2015 at 08:14:48AM CEST, sfel...@gmail.com wrote:
On Mon, Aug 17, 2015 at 10:55 PM, Jiri Pirko j...@resnulli.us wrote:
 Tue, Aug 18, 2015 at 12:36:17AM CEST, sfel...@gmail.com wrote:
From: Scott Feldman sfel...@gmail.com

 snip

+  rocker-dbg_dir = debugfs_create_dir(dbg_dir_name, rocker_dbg_root);
+  if (!rocker-dbg_dir)

 You still check the retval here and

It's OK.  See include/linux/debugfs.h when CONFIG_DEBUG_FS=n.
debugfs_create_dir() returns ERR_PTR(-ENODEV), which is !NULL.

 Does not make sense to check it for NULL then. It is never NULL...

It can be NULL when CONFIG_DEBUG_FS=y.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Jiri Pirko 
Tue, Aug 18, 2015 at 09:21:15AM CEST, sfel...@gmail.com wrote:
On Mon, Aug 17, 2015 at 11:48 PM, Jiri Pirko j...@resnulli.us wrote:
 Tue, Aug 18, 2015 at 08:14:48AM CEST, sfel...@gmail.com wrote:
On Mon, Aug 17, 2015 at 10:55 PM, Jiri Pirko j...@resnulli.us wrote:
 Tue, Aug 18, 2015 at 12:36:17AM CEST, sfel...@gmail.com wrote:
From: Scott Feldman sfel...@gmail.com

 snip

+  rocker-dbg_dir = debugfs_create_dir(dbg_dir_name, rocker_dbg_root);
+  if (!rocker-dbg_dir)

 You still check the retval here and

It's OK.  See include/linux/debugfs.h when CONFIG_DEBUG_FS=n.
debugfs_create_dir() returns ERR_PTR(-ENODEV), which is !NULL.

 Does not make sense to check it for NULL then. It is never NULL...

It can be NULL when CONFIG_DEBUG_FS=y.

You are right, this inconsistency looks odd to me though.

Anyway,

Acked-by: Jiri Pirko j...@resnulli.us

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Scott Feldman 
On Tue, Aug 18, 2015 at 7:01 AM, Andrew Lunn and...@lunn.ch wrote:
 On Mon, Aug 17, 2015 at 03:36:17PM -0700, sfel...@gmail.com wrote:
 From: Scott Feldman sfel...@gmail.com

  tree /sys/kernel/debug/rocker
 /sys/kernel/debug/rocker
 ? 525400123501
 ? fdb_tbl
 ? internal_vlan_tbl
 ? neigh_tbl
 ? of_dpa_flow_tbl
 ? of_dpa_group_tbl

 1 directory, 5 files

  cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
 ifindex 5 ref_count 1 vlan 3843
 ifindex 7 ref_count 2 vlan 3840
 ifindex 4 ref_count 1 vlan 3842

  cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
 learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
 learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840

  cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
 11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
 11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1

 Hi Scott

 David is not so keen no debugfs stuff. He already NACKed adding more
 than what is currently in DSA:

 https://lkml.org/lkml/2015/7/11/8

That patch added writable debugfs files, which I can see might be used
as a back-door to program hardware.  That does seem bad.

 I think the key thing from David's message is:

 Fetching information should be done by well typed, generic,
 interfaces that apply to any similar device or object.

 So rather than splattering rocker stuff in debugfs, we should really
 be thinking about an interface which works well for both Rocker and
 DSA, i.e. generic, and keeps David happy by being typed.

 No idea what that actually is, not thought about it yet.

Rocker debugfs files are read-only and dump internal tables that are
very specific to the (rocker) device.  I don't see how these could be
generic as each device/driver will have it's own unique data
structures.

I'm OK with not including debugfs in rocker even for these read-only
files, but I find them very useful during development/debugging, and I
could see their value in troubleshooting issues with others using
rocker.

Writable debugfs files is another story.

-scott
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Andrew Lunn 
On Tue, Aug 18, 2015 at 10:18:51AM -0700, Scott Feldman wrote:
 On Tue, Aug 18, 2015 at 7:01 AM, Andrew Lunn and...@lunn.ch wrote:
  On Mon, Aug 17, 2015 at 03:36:17PM -0700, sfel...@gmail.com wrote:
  From: Scott Feldman sfel...@gmail.com
 
   tree /sys/kernel/debug/rocker
  /sys/kernel/debug/rocker
  ? 525400123501
  ? fdb_tbl
  ? internal_vlan_tbl
  ? neigh_tbl
  ? of_dpa_flow_tbl
  ? of_dpa_group_tbl
 
  1 directory, 5 files
 
   cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
  ifindex 5 ref_count 1 vlan 3843
  ifindex 7 ref_count 2 vlan 3840
  ifindex 4 ref_count 1 vlan 3842
 
   cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
  learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
  learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840
 
   cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
  11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
  11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1
 
  Hi Scott
 
  David is not so keen no debugfs stuff. He already NACKed adding more
  than what is currently in DSA:
 
  https://lkml.org/lkml/2015/7/11/8
 
 That patch added writable debugfs files, which I can see might be used
 as a back-door to program hardware.  That does seem bad.

I fully agreed with respect to write. But if you read the whole
message, David is also not happy with read only.

I think before you spend too much more time on this, you need some
indication from David if he is going to merge it or not.

   Andrew
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread David Miller 
From: Jiri Pirko j...@resnulli.us
Date: Tue, 18 Aug 2015 07:55:55 +0200

 Tue, Aug 18, 2015 at 12:36:17AM CEST, sfel...@gmail.com wrote:
+static int rocker_probe_debugfs_init(struct rocker *rocker)
+{
+ char dbg_dir_name[sizeof(rocker-hw.id) * 2 + 1];
+
+ sprintf(dbg_dir_name, %*phN, (int)sizeof(rocker-hw.id),
+ rocker-hw.id);
 
 You can use PCI address here. Might be better.

This absolutely will not be unique in a multi-domain PCI configuration.

It is arguable whether that matters or not under qemu, but it's a bad
precedence to say that PCI addresses will be unique, they absolutely
are not unique between devices even of the same exact type.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Scott Feldman 
On Tue, Aug 18, 2015 at 11:19 AM, Andrew Lunn and...@lunn.ch wrote:
 On Tue, Aug 18, 2015 at 10:18:51AM -0700, Scott Feldman wrote:
 On Tue, Aug 18, 2015 at 7:01 AM, Andrew Lunn and...@lunn.ch wrote:
  On Mon, Aug 17, 2015 at 03:36:17PM -0700, sfel...@gmail.com wrote:
  From: Scott Feldman sfel...@gmail.com
 
   tree /sys/kernel/debug/rocker
  /sys/kernel/debug/rocker
  ? 525400123501
  ? fdb_tbl
  ? internal_vlan_tbl
  ? neigh_tbl
  ? of_dpa_flow_tbl
  ? of_dpa_group_tbl
 
  1 directory, 5 files
 
   cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
  ifindex 5 ref_count 1 vlan 3843
  ifindex 7 ref_count 2 vlan 3840
  ifindex 4 ref_count 1 vlan 3842
 
   cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
  learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
  learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840
 
   cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
  11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
  11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1
 
  Hi Scott
 
  David is not so keen no debugfs stuff. He already NACKed adding more
  than what is currently in DSA:
 
  https://lkml.org/lkml/2015/7/11/8

 That patch added writable debugfs files, which I can see might be used
 as a back-door to program hardware.  That does seem bad.

 I fully agreed with respect to write. But if you read the whole
 message, David is also not happy with read only.

 I think before you spend too much more time on this, you need some
 indication from David if he is going to merge it or not.

David, please give us guidance on debugfs in drivers/net.  Is there
some criteria we can define to know when it's OK to use debugfs?

-scott
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread David Miller 
From: Scott Feldman sfel...@gmail.com
Date: Tue, 18 Aug 2015 13:37:56 -0700

 On Tue, Aug 18, 2015 at 11:19 AM, Andrew Lunn and...@lunn.ch wrote:
 On Tue, Aug 18, 2015 at 10:18:51AM -0700, Scott Feldman wrote:
 On Tue, Aug 18, 2015 at 7:01 AM, Andrew Lunn and...@lunn.ch wrote:
  On Mon, Aug 17, 2015 at 03:36:17PM -0700, sfel...@gmail.com wrote:
  From: Scott Feldman sfel...@gmail.com
 
   tree /sys/kernel/debug/rocker
  /sys/kernel/debug/rocker
  ? 525400123501
  ? fdb_tbl
  ? internal_vlan_tbl
  ? neigh_tbl
  ? of_dpa_flow_tbl
  ? of_dpa_group_tbl
 
  1 directory, 5 files
 
   cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
  ifindex 5 ref_count 1 vlan 3843
  ifindex 7 ref_count 2 vlan 3840
  ifindex 4 ref_count 1 vlan 3842
 
   cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
  learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
  learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840
 
   cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
  11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
  11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1
 
  Hi Scott
 
  David is not so keen no debugfs stuff. He already NACKed adding more
  than what is currently in DSA:
 
  https://lkml.org/lkml/2015/7/11/8

 That patch added writable debugfs files, which I can see might be used
 as a back-door to program hardware.  That does seem bad.

 I fully agreed with respect to write. But if you read the whole
 message, David is also not happy with read only.

 I think before you spend too much more time on this, you need some
 indication from David if he is going to merge it or not.
 
 David, please give us guidance on debugfs in drivers/net.  Is there
 some criteria we can define to know when it's OK to use debugfs?

The less you use it the better, seriously.

I see some drivers where the foo_debugfs.c file is larger than the rest
of the driver.  Once people start using it, it's like crack, and they
dump every single debugging widget they found useful at some point into
there.

This is not what we want.  Most things I see in debugfs support was
probably useful for debugging one particular bug but then it was never
really useful again in the future.  Those kinds of things can be done
locally in someone's tree.

I often see various kinds of statistics ending up in these things,
or register dumps, both of which are 'ethtool' or similar material.

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-18 Thread Andrew Lunn 
On Mon, Aug 17, 2015 at 03:36:17PM -0700, sfel...@gmail.com wrote:
 From: Scott Feldman sfel...@gmail.com
 
  tree /sys/kernel/debug/rocker
 /sys/kernel/debug/rocker
 ? 525400123501
 ? fdb_tbl
 ? internal_vlan_tbl
 ? neigh_tbl
 ? of_dpa_flow_tbl
 ? of_dpa_group_tbl
 
 1 directory, 5 files
 
  cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
 ifindex 5 ref_count 1 vlan 3843
 ifindex 7 ref_count 2 vlan 3840
 ifindex 4 ref_count 1 vlan 3842
 
  cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
 learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
 learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840
 
  cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
 11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
 11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1

Hi Scott

David is not so keen no debugfs stuff. He already NACKed adding more
than what is currently in DSA:

https://lkml.org/lkml/2015/7/11/8

I think the key thing from David's message is:

 Fetching information should be done by well typed, generic,
 interfaces that apply to any similar device or object.

So rather than splattering rocker stuff in debugfs, we should really
be thinking about an interface which works well for both Rocker and
DSA, i.e. generic, and keeps David happy by being typed.

No idea what that actually is, not thought about it yet.

 Andrew
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-17 Thread sfeldma 
From: Scott Feldman sfel...@gmail.com

 tree /sys/kernel/debug/rocker
/sys/kernel/debug/rocker
└── 525400123501
├── fdb_tbl
├── internal_vlan_tbl
├── neigh_tbl
├── of_dpa_flow_tbl
└── of_dpa_group_tbl

1 directory, 5 files

 cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
ifindex 5 ref_count 1 vlan 3843
ifindex 7 ref_count 2 vlan 3840
ifindex 4 ref_count 1 vlan 3842

 cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840

 cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1

 cat /sys/kernel/debug/rocker/525400123501/of_dpa_flow_tbl
cmd 3 cookie 15 priority 3  tbl aclin_pport 2 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3841 ip proto 0/0 
ip tos 0/0 group_id 0x0f01
cmd 3 cookie 2  priority 0  tbl term_mac   in_pport 1 eth_type 0x0800 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie 1f priority 3  tbl bridge 00:02:00:00:00:00 vlan_id 3840 
tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 4  priority 1  tbl vlan   in_pport 2 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3841
cmd 3 cookie 20 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.1 
goto_tbl acl group_id 0x2000
cmd 3 cookie 21 priority 3  tbl bridge 00:02:00:00:01:00 vlan_id 3841 
tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 16 priority 2  tbl aclin_pport 2 eth_type 0x0806 
vlan_id 3841 ip proto 0/0 ip tos 0/0 group_id 0x0f01
cmd 3 cookie 12 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.0 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 9  priority 3  tbl aclin_pport 1 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3840 ip proto 0/0 
ip tos 0/0 group_id 0x0f00
cmd 3 cookie 6  priority 0  tbl term_mac   in_pport 2 eth_type 0x86dd 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 4 cookie 0  priority 1  tbl ig_portin_pport 0/0x goto_tbl 
vlan
cmd 4 cookie e  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.3 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 1  priority 1  tbl vlan   in_pport 1 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3840
cmd 3 cookie 24 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.4/255.255.255.252 goto_tbl acl group_id 0x2000
cmd 4 cookie 14 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.10 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 2c priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.4 
goto_tbl acl group_id 0x2001
cmd 3 cookie 17 priority 1  tbl term_mac   in_pport 2 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 26 priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.3 
goto_tbl acl group_id 0x2000
cmd 3 cookie 2e priority 30 tbl ucast_routing  eth_type 0x0800 12.0.0.2 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 22 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.9 
goto_tbl acl group_id 0x2001
cmd 3 cookie 1c priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.8/255.255.255.252 goto_tbl acl group_id 0x0f01
cmd 3 cookie 18 priority 1  tbl term_mac   in_pport 2 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 5  priority 0  tbl term_mac   in_pport 2 eth_type 0x0800 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie a  priority 2  tbl aclin_pport 1 eth_type 0x0806 
vlan_id 3840 ip proto 0/0 ip tos 0/0 group_id 0x0f00
cmd 4 cookie 1a priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.11 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 1e priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.8 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 3  priority 0  tbl term_mac   in_pport 1 eth_type 0x86dd 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie b  priority 1  tbl term_mac   in_pport 1 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3840 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 4 cookie 8  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.2 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 10 priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.0/255.255.255.252 goto_tbl acl group_id 0x0f00
cmd 3 cookie 28 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.12/255.255.255.252 goto_tbl acl group_id 0x2001
cmd 3 cookie c  priority 1  tbl term_mac   in_pport 1 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3840 goto_tbl mcast_routing 
copy_to_cpu 1

 cat /sys/kernel/debug/rocker/525400123501/of_dpa_group_tbl
cmd 7 group_id 0x0f00 (L2

Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables

2015-08-17 Thread Jiri Pirko 
Tue, Aug 18, 2015 at 12:36:17AM CEST, sfel...@gmail.com wrote:
From: Scott Feldman sfel...@gmail.com

 tree /sys/kernel/debug/rocker
/sys/kernel/debug/rocker
└── 525400123501
├── fdb_tbl
├── internal_vlan_tbl
├── neigh_tbl
├── of_dpa_flow_tbl
└── of_dpa_group_tbl

1 directory, 5 files

 cat /sys/kernel/debug/rocker/525400123501/internal_vlan_tbl
ifindex 5 ref_count 1 vlan 3843
ifindex 7 ref_count 2 vlan 3840
ifindex 4 ref_count 1 vlan 3842

 cat /sys/kernel/debug/rocker/525400123501/fdb_tbl
learned 1 pport 1 addr 00:02:00:00:02:00 vlan 3840
learned 1 pport 2 addr 00:02:00:00:03:00 vlan 3840

 cat /sys/kernel/debug/rocker/525400123501/neigh_tbl
11.0.0.9 dev sw1p2 ref_count 3 index 1 dst 00:02:00:00:01:00 ttl_check 1
11.0.0.1 dev sw1p1 ref_count 3 index 0 dst 00:02:00:00:00:00 ttl_check 1

 cat /sys/kernel/debug/rocker/525400123501/of_dpa_flow_tbl
cmd 3 cookie 15 priority 3  tbl aclin_pport 2 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3841 ip proto 0/0 
ip tos 0/0 group_id 0x0f01
cmd 3 cookie 2  priority 0  tbl term_mac   in_pport 1 eth_type 0x0800 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie 1f priority 3  tbl bridge 00:02:00:00:00:00 vlan_id 3840 
tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 4  priority 1  tbl vlan   in_pport 2 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3841
cmd 3 cookie 20 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.1 
goto_tbl acl group_id 0x2000
cmd 3 cookie 21 priority 3  tbl bridge 00:02:00:00:01:00 vlan_id 3841 
tunnel_id 0 goto_tbl acl group_id 0x copy_to_cpu 0
cmd 3 cookie 16 priority 2  tbl aclin_pport 2 eth_type 0x0806 
vlan_id 3841 ip proto 0/0 ip tos 0/0 group_id 0x0f01
cmd 3 cookie 12 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.0 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 9  priority 3  tbl aclin_pport 1 
01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 eth_type 0x vlan_id 3840 ip proto 0/0 
ip tos 0/0 group_id 0x0f00
cmd 3 cookie 6  priority 0  tbl term_mac   in_pport 2 eth_type 0x86dd 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 4 cookie 0  priority 1  tbl ig_portin_pport 0/0x goto_tbl 
vlan
cmd 4 cookie e  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.3 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 1  priority 1  tbl vlan   in_pport 1 vlan_id 0 goto_tbl 
term_mac untagged 1 new_vlan_id 3840
cmd 3 cookie 24 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.4/255.255.255.252 goto_tbl acl group_id 0x2000
cmd 4 cookie 14 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.10 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 2c priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.4 
goto_tbl acl group_id 0x2001
cmd 3 cookie 17 priority 1  tbl term_mac   in_pport 2 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 26 priority 20 tbl ucast_routing  eth_type 0x0800 12.0.0.3 
goto_tbl acl group_id 0x2000
cmd 3 cookie 2e priority 30 tbl ucast_routing  eth_type 0x0800 12.0.0.2 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 22 priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.9 
goto_tbl acl group_id 0x2001
cmd 3 cookie 1c priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.8/255.255.255.252 goto_tbl acl group_id 0x0f01
cmd 3 cookie 18 priority 1  tbl term_mac   in_pport 2 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3841 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 3 cookie 5  priority 0  tbl term_mac   in_pport 2 eth_type 0x0800 
52:54:00:12:35:02 vlan_id 3841 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie a  priority 2  tbl aclin_pport 1 eth_type 0x0806 
vlan_id 3840 ip proto 0/0 ip tos 0/0 group_id 0x0f00
cmd 4 cookie 1a priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.11 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 1e priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.8 
goto_tbl acl group_id 0x0f01
cmd 3 cookie 3  priority 0  tbl term_mac   in_pport 1 eth_type 0x86dd 
52:54:00:12:35:01 vlan_id 3840 goto_tbl ucast_routing copy_to_cpu 0
cmd 3 cookie b  priority 1  tbl term_mac   in_pport 1 eth_type 0x0800 
01:00:5e:00:00:00/ff:ff:ff:80:00:00 vlan_id 3840 goto_tbl mcast_routing 
copy_to_cpu 1
cmd 4 cookie 8  priority 0  tbl ucast_routing  eth_type 0x0800 11.0.0.2 
goto_tbl acl group_id 0x0f00
cmd 3 cookie 10 priority 0  tbl ucast_routing  eth_type 0x0800 
11.0.0.0/255.255.255.252 goto_tbl acl group_id 0x0f00
cmd 3 cookie 28 priority 20 tbl ucast_routing  eth_type 0x0800 
11.0.0.12/255.255.255.252 goto_tbl acl group_id 0x2001
cmd 3 cookie c  priority 1  tbl term_mac   in_pport 1 eth_type 0x86dd 
33:33:00:00:00:00/ff:ff:00:00:00:00 vlan_id 3840 goto_tbl mcast_routing 
copy_to_cpu 1

 cat