From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 478E5567C for ; Wed, 25 May 2016 19:51:16 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 25 May 2016 10:51:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,364,1459839600"; d="scan'208";a="962253156" Received: from kjtomczy-mobl.ger.corp.intel.com ([10.252.31.37]) by orsmga001.jf.intel.com with SMTP; 25 May 2016 10:51:13 -0700 Received: by (sSMTP sendmail emulation); Wed, 25 May 2016 18:51:12 +0025 Date: Wed, 25 May 2016 18:51:12 +0100 From: Bruce Richardson To: Stephen Hurd Cc: dev@dpdk.org Message-ID: <20160525175112.GD10676@bricha3-MOBL3> References: <1463179589-82681-1-git-send-email-stephen.hurd@broadcom.com> <1463179589-82681-9-git-send-email-stephen.hurd@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463179589-82681-9-git-send-email-stephen.hurd@broadcom.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v2 09/40] bnxt: add L2 filter alloc/init/free X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 17:51:16 -0000 On Fri, May 13, 2016 at 03:45:58PM -0700, Stephen Hurd wrote: > Add the L2 filter structure and the alloc/init/free functions for > dealing with them. > The DPDK ethdev API has filtering APIs, but this code is not made accessible via those APIs. If that link is added via later patches, then that should be documented in the commit message here. > +/* hwrm_cfa_l2_filter_alloc */ > +/* > + * Description: An L2 filter is a filter resource that is used to identify a > + * vnic or ring for a packet based on layer 2 fields. Layer 2 fields for > + * encapsulated packets include both outer L2 header and/or inner l2 header of > + * encapsulated packet. The L2 filter resource covers the following OS specific > + * L2 filters. Linux/FreeBSD (per function): # Broadcast enable/disable # List > + * of individual multicast filters # All multicast enable/disable filter # > + * Unicast filters # Promiscuous mode VMware: # Broadcast enable/disable (per > + * physical function) # All multicast enable/disable (per function) # Unicast > + * filters per ring or vnic # Promiscuous mode per PF Windows: # Broadcast > + * enable/disable (per physical function) # List of individual multicast filters > + * (Driver needs to advertise the maximum number of filters supported) # All > + * multicast enable/disable per physical function # Unicast filters per vnic # > + * Promiscuous mode per PF Implementation notes on the use of VNIC in this > + * command: # By default, these filters belong to default vnic for the function. > + * # Once these filters are set up, only destination VNIC can be modified. # If > + * the destination VNIC is not specified in this command, then the HWRM shall > + * only create an l2 context id. HWRM Implementation notes for multicast > + * filters: # The hwrm_filter_alloc command can be used to set up multicast > + * filters (perfect match or partial match). Each individual function driver can > + * set up multicast filters independently. # The HWRM needs to keep track of > + * multicast filters set up by function drivers and maintain multicast group > + * replication records to enable a subset of functions to receive traffic for a > + * specific multicast address. # When a specific multicast filter cannot be set, > + * the HWRM shall return an error. In this error case, the driver should fall > + * back to using one general filter (rather than specific) for all multicast > + * traffic. # When the SR-IOV is enabled, the HWRM needs to additionally track > + * source knockout per multicast group record. Examples of setting unicast > + * filters: For a unicast MAC based filter, one can use a combination of the > + * fields and masks provided in this command to set up the filter. Below are > + * some examples: # MAC + no VLAN filter: This filter is used to identify > + * traffic that does not contain any VLAN tags and matches destination (or > + * source) MAC address. This filter can be set up by setting only l2_addr field > + * to be a valid field. All other fields are not valid. The following value is > + * set for l2_addr. l2_addr = MAC # MAC + Any VLAN filter: This filter is used > + * to identify traffic that carries single VLAN tag and matches (destination or > + * source) MAC address. This filter can be set up by setting only l2_addr and > + * l2_ovlan_mask fields to be valid fields. All other fields are not valid. The > + * following values are set for those two valid fields. l2_addr = MAC, > + * l2_ovlan_mask = 0xFFFF # MAC + no VLAN or VLAN ID=0: This filter is used to > + * identify untagged traffic that does not contain any VLAN tags or a VLAN tag > + * with VLAN ID = 0 and matches destination (or source) MAC address. This filter > + * can be set up by setting only l2_addr and l2_ovlan fields to be valid fields. > + * All other fields are not valid. The following value are set for l2_addr and > + * l2_ovlan. l2_addr = MAC, l2_ovlan = 0x0 # MAC + no VLAN or any VLAN: This > + * filter is used to identify traffic that contains zero or 1 VLAN tag and > + * matches destination (or source) MAC address. This filter can be set up by > + * setting only l2_addr, l2_ovlan, and l2_mask fields to be valid fields. All > + * other fields are not valid. The following value are set for l2_addr, > + * l2_ovlan, and l2_mask fields. l2_addr = MAC, l2_ovlan = 0x0, l2_ovlan_mask = > + * 0xFFFF # MAC + VLAN ID filter: This filter can be set up by setting only > + * l2_addr, l2_ovlan, and l2_ovlan_mask fields to be valid fields. All other > + * fields are not valid. The following values are set for those three valid > + * fields. l2_addr = MAC, l2_ovlan = VLAN ID, l2_ovlan_mask = 0xF000 > + */ This comment could do with clean-up to improve formatting and readability. I'm also not sure that an explanation of this size is best placed as a comment on a function. However, I'm also not sure where this information is best placed as these filter functions are all internal to the driver, and not part of the common DPDK NIC APIs. Regards, /Bruce