From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id 09F6A677B for ; Fri, 31 Oct 2014 09:36:18 +0100 (CET) Received: by mail-wi0-f169.google.com with SMTP id n3so702428wiv.4 for ; Fri, 31 Oct 2014 01:45:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=LLCZGV5dV/yJptKJiaArJJEMQYgpOtiVQqDq5GPdO6M=; b=MQDgJESO5u/OjkR6EomIYR6gakN0qgM9nRRBnt0s7u+OVX++6tWj8PK1Qy0/x7mAeN mNbBa3CXurUYCy4dvu/4fhtawYP1HJ+JMPfUfm3RQGX8RI7KeIygC1ipIjfB1LXejuNP frqyfvMHH4Qd+meReDyKixaOc3t3+zVzuhRSk2u0xZrcjBvH9KSw9Y8Vq2XNO1NQAJIx 0jSYvNibCCIOpaoh+Plba/YRfyCCdYOy5YDnzxFKzqx50if/gRzBw8OTIOp4qUIu4u1m UcpLKK9+i9NhPkL7WfZgem/2fzv4oov/XunnETe8zs92T1lhy2DhOwtqeSU8tvKtU96N Uklg== X-Gm-Message-State: ALoCoQmqv7nC7gypIomz16eOj8qogm7tIjQfVHujY2rqZGIW0PZgQov53JBbHcmAyXfN+zT5gLdM X-Received: by 10.180.75.116 with SMTP id b20mr2231129wiw.49.1414745117815; Fri, 31 Oct 2014 01:45:17 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id t9sm11293008wjf.41.2014.10.31.01.45.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Oct 2014 01:45:17 -0700 (PDT) From: Thomas Monjalon To: "Wu, Jingjing" Date: Fri, 31 Oct 2014 09:44:58 +0100 Message-ID: <4699150.INYaCBBBvY@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.1-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: <9BB6961774997848B5B42BEC655768F8B26609@SHSMSX104.ccr.corp.intel.com> References: <1411628369-29532-1-git-send-email-jingjing.wu@intel.com> <1607705.DDyl0z8Nv8@xps13> <9BB6961774997848B5B42BEC655768F8B26609@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: define ctrl_pkt filter type and its structure 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: Fri, 31 Oct 2014 08:36:18 -0000 Hi Jingjing, I'm sorry, but your explanations are not sufficient. Please keep in mind that the user of the API don't know i40e internals. 2014-10-31 07:05, Wu, Jingjing: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2014-10-22 16:19, Jingjing Wu: > > > +/** > > > + * Define all structures for Control Packet Filter type corresponding with > > specific operations. > > > + */ > > > > Please explain what is a control packet. > > A control element in Fortville can be used to receive control packets and control other switching elements. Control packet filter can filter control packet (such as LLDP) to different queues in receive and identify the switch element that should process the packets in transmit. > At the same time, we also can use this filter to route non-control packets to queue or other engine by filtering mac and ether_type. The name "control packet filter" comes from Fortville. I still don't know what is a control packet. > > > +#define RTE_CONTROL_PACKET_FLAGS_IGNORE_MAC 0x0001 > > > +#define RTE_CONTROL_PACKET_FLAGS_DROP 0x0002 > > > +#define RTE_CONTROL_PACKET_FLAGS_TO_QUEUE 0x0004 > > > +#define RTE_CONTROL_PACKET_FLAGS_TX 0x0008 > > > +#define RTE_CONTROL_PACKET_FLAGS_RX 0x0000 > > > > Flag RX is 0? > > Yes, RX is default value. Maybe it need to be removed. No, it doesn't need to be removed. But a flag must not be 0. 0 means none. It's impossible to disable this flag. Moreover, you should comment each flag. > > > +/** > > > + * A structure used to define the control packet filter entry > > > + * to support RTE_ETH_FILTER_CTRL_PKT with RTE_ETH_FILTER_ADD > > > + * and RTE_ETH_FILTER_DELETE operations. > > > + */ > > > +struct rte_ctrl_pkt_filter { > > > + struct ether_addr mac_addr; /**< mac address to match. */ > > > + uint16_t ether_type; /**< ether type to match */ > > > + uint16_t flags; /**< options for filter's behavior*/ > > > + uint16_t dest_id; /**< destination vsi id or pool id*/ > > > > vsi id and pool id cannot be understood in a generic context. > > Please explain what you mean and why queue is not enough. > > If queue is not specified, dest_id defines which element (vsi) will get the packet. > If queue is specified, the queue need belong to the destination element. You really need to define what is a vsi id and pool id. These notions are not known in the API layer. > > > + uint16_t queue; /**< queue assign to if TO QUEUE flag is set > > */ > > > > TO QUEUE is not defined. Is it really needed? > > > TO QUEUE is just the flag RTE_CONTROL_PACKET_FLAGS_TO_QUEUE above. OK, please use the same wording or users will get lost. -- Thomas