netdev - Re: [PATCH net-next] switchdev: add support for fdb add/del/dump via switchdev_port

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 11 May 2015 09:15:14 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	"Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] switchdev: add support for fdb add/del/dump
 via switchdev_port_obj ops.

On 05/08/15 16:58, Scott Feldman wrote:
> On Fri, May 8, 2015 at 5:05 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
>> On 05/07/15 00:42, Samudrala, Sridhar wrote:
>>>

> Bottom line is netlink is not great for in-kernel driver APIs.  Look
> at the fdb and bridge_set/get/dellink ndo ops in netdevice.h to see
> what kind of horse already left the barn.  It's a swayback nag blind
> in one eye and deaf in the other eye.  The problems are:
>

Scott, I dont disagree with you in regarding to the fdb/brport.
The barn has left the deaf-in-the-other-eye horse on that one (yes,
I said that on purpose;->) and it may even make sense to write a
different interface from user  space. I could add more to your list
(why are 8 bits being used to represent a single bit flag for example,
etc).
But what i am worried about is you are setting a trend. I would hate
for this to start looking like SAI when we've had shit working really
well.
You'll find the L3 stuff is more solid in terms of its netlink usage.
But even for the bridge stuff, describing an object as, hiearachy of

An "add" looking like:
   RTM_NEWNEIGH,
      {pointer to attributeid, pointer to attribute value}+

whereas the pointers are to the original TLV (which is still sitting
somewhere in memory) sounds useful.

I dont want to slow you down and i dont have code to demonstrate it -
but hoping I dont need to.

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