netdev - Re: [patch net-next RFC 0/8] Add support for pipeline debug (dpipe)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Feb 2017 23:20:20 +0200
From:   arkadis <arkadis@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>
CC:     <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <idosch@...lanox.com>, <mlxsw@...lanox.com>, <jhs@...atatu.com>,
        <ivecera@...hat.com>, <roopa@...ulusnetworks.com>,
        <f.fainelli@...il.com>, <vivien.didelot@...oirfairelinux.com>,
        <john.fastabend@...il.com>
Subject: Re: [patch net-next RFC 0/8] Add support for pipeline debug (dpipe)

On 02/16/2017 06:48 PM, Jiri Pirko wrote:
> Thu, Feb 16, 2017 at 05:40:29PM CET, andrew@...n.ch wrote:
>> On Thu, Feb 16, 2017 at 05:20:00PM +0100, Jiri Pirko wrote:
>>> Thu, Feb 16, 2017 at 05:11:50PM CET, andrew@...n.ch wrote:
>>>> On Thu, Feb 16, 2017 at 04:22:36PM +0100, Jiri Pirko wrote:
>>>>> From: Jiri Pirko <jiri@...lanox.com>
>>>>>
>>>>> Arkadi says:
>>>>
>>>> Hi Jiri, Arkadi
>>>>
>>>> It is not mentioned here, but i assume you have a followup patchset
>>>> which extends the devlink command to enumerate what tables are
>>>> available and to print them?
>>>
>>> DEVLINK_CMD_DPIPE_TABLES_GET
>>> command gets you all tables. But it gets it with the content. I guess
>>> there could be some command to instruct devlink just to dump tables
>>> without the content.
>>
>> This does not sound like it will scale very well, as the number of
>> tables increases. Also, at least in the DSA world, getting a table can
>> be an expensive operation, lots of MDIO/SPI/I2C transactions. I'd
>> prefer to be able to just get one specific table, rather than dump
>> them all.
> 
> Understood. We'll try to figure out how to make this done.
> 

Get tables should give general table description including name,
behavior in terms of match/action, max entries, lookup way (TCAM, hash)
etc. To get the actual entries you have to use dump entries on a
per-table resolution. So you need to use DEVLINK_DPIPE_ENTRIES_GET on
a specific table.

First, one can see the tables in order to understand the hardware
structure (for debug purposes or just to gain visibility into the
offload process), and then dump the specific table of interest.

Some tables for example TCAM memory can be divided into regions.
So it is reasonable to aggregate tables under other tables (kind of
a zoom in) and be able to dump all the TCAM with one dump operation and
yet gain access of dumping each TCAM region separately.

Some things are currently missing like the above logic. Furthermore
the interaction between tables should be exported as well so that the
user receives graph of table interaction.

As I see it, all this behavior can be added and this basic API stays
valid.

> 
>>
>> I can however see cases when it does make sense to have an atomic,
>> dump everything operation, where you can trust to be consistent across
>> tables.
>>
>>>> Hopefully it will be more obvious when the user space patches are
>>>> available.
>>>
>>> I'll ask Arkadi to send the devlink userspace patches as RFC as well.
>>
>> Great, thanks.
>>
>>       Andrew