From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Subject: Re: [PATCH net-next] switchdev: add support for fdb add/del/dump via switchdev_port_obj ops. Date: Fri, 08 May 2015 08:05:08 -0400 Message-ID: <554CA674.8040905@mojatatu.com> References: <1430949253-6358-1-git-send-email-sridhar.samudrala@intel.com> <554AA530.7000702@mojatatu.com> <554AED2F.80006@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: "Samudrala, Sridhar" , sfeldma@gmail.com, netdev@vger.kernel.org Return-path: Received: from mail-ie0-f172.google.com ([209.85.223.172]:35726 "EHLO mail-ie0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752666AbbEHMFL (ORCPT ); Fri, 8 May 2015 08:05:11 -0400 Received: by ieczm2 with SMTP id zm2so61469442iec.2 for ; Fri, 08 May 2015 05:05:11 -0700 (PDT) In-Reply-To: <554AED2F.80006@intel.com> Sender: netdev-owner@vger.kernel.org List-ID: On 05/07/15 00:42, Samudrala, Sridhar wrote: > > > On 5/6/2015 4:35 PM, Jamal Hadi Salim wrote: >> On 05/06/15 17:54, Sridhar Samudrala wrote: >> So i raised this earlier. DaveM also chimed in - but it seems still >> in there. >> i havent been following the discussion and i may have missed >> the agreement to keep the new IDs. Could we not just have used netlink >> IDs (as opposed to a new SWITCHDEV_OBJ_PORT_FDB id)? > > I think you are referring to switch port attributes. See Scott's > response here on > using netlink IDs for attributes. > http://thread.gmane.org/gmane.linux.network/357694/focus=357921 > > This patch is adding 'fdb' as new switch port object. It is similar to > other > objects like 'VLAN' and 'FIB' that are added by Scott's patches. Sorry I missed it - but I am not making sense of Scott's answer. The danger of adding these visible APIs is it would be too late to take them out once they hit the wild (Dave's famous "the horse has left the barn" or look at Jiri's netconf presentation). I hate to do this but taking longer to discuss these issues is important. I will agree that we need some common id to represent the grouping of the fdb entries - i will contend using netlink verb-nouns is sufficient. Example: RTM_NEWNEIGH is clearly refering to a modify or create on an fdb. The other issue is how to define optionality. So lets start with the fdb object: While i would agree they are common, Vlans are optional in an fdb entry. The only two items that must be present for an fdb entry are a dstmac address and an egress port. some low end switches dont do vlans. Therefore there are two IDs that must always be present: The object id for a port is the ifindex. The object id for a mac address is NDA_LLADDR The object id for a vlan is NDA_VLAN Then there are of course a gazillion other features which may be one-of such as the fdb partition id in the netgear switch Ben was playing. I understand the earlier arguement of not needing to have multiple parsings of the same thing. But providing parseable options means never having to change what the object struct looks like. Just provide a scatter list of pointers to the different netlink attr-val pairs so it doesnt need to be re-parsed. Otherwise we are re-inventing things and start to look like vendor SDKs. cheers, jamal