From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id D736437B2 for ; Mon, 14 Dec 2015 16:11:18 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id p66so66612799wmp.1 for ; Mon, 14 Dec 2015 07:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=d4aT5d7cgDGJAjJI75l63VBMsjUwoHp1Rxoh+5RkEBI=; b=HvP2Wybewc+FxTkq048qlk8UoiCW7j8btbZPtRnZXxpkE9sJPEvjaMXIDCbHomqAXh KCH1Frea5mUBkf5/KK7OPw1VT+Vq4DtGKLYm+dtfGI8Czj7FzV/KeEBjB4clHWawW2Ny n/LjJI/NNb1ZNV9lC2TUTwmMIGQiZOcKWnp+6GYi3lCg1MsUUqUmKlEAxHteS7BwCDnS jiVZiSzqoZQCPNk9MBcemrdZmyvsngTr80gkm81pg7Snb8/sFBxaCXYvnUJv+khJMRly AeFEOyKVxyOu+Rjtn8yt1ksX27AU+1R6+nZ0WZowFKi1Iq5t/JQQTuoVaoXSgZsUkifG UyyQ== 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=d4aT5d7cgDGJAjJI75l63VBMsjUwoHp1Rxoh+5RkEBI=; b=SCCo/2wgpj6kwhyoI0pQz5DVuY/H+j9XD2FmRm1P8K6K/yoymLczzkeaw1l3c7J8wU SYEaR5CMOY4xfAa19WmjK5JSfZlvkz7MctNEG5GPVgHdj6bJDUQBQYQNvcO6S8mnv31d iScq6BXruONJyLpEgZXf2Z4Hjuxf+CUSph/oE5r8O1Fc3Zi+y9m/DrnLHtS80VTr7nYS FWjqFeME6fW5KTae6WsOczK6DHJCQicMsqP35yYk5uOw0JpvpaXDEGI3bmSLfzTPIlW2 fHrxNlfDuMm81cTWOx7fvfH8C/GWgBe7691uqmAEa2CGVj3m+pPlrw1MxtHMhNtIhI6P gPfw== X-Gm-Message-State: ALoCoQnEYNEv8K2vqWnVGXO1JKMJLsYJ7FFICSQhrlIeE7e3vnlXDaLbXf6uMxOH/xbGGurJX1euzq/HgOXBl75B4EUFVx51/w== X-Received: by 10.194.62.14 with SMTP id u14mr38400385wjr.24.1450105877608; Mon, 14 Dec 2015 07:11:17 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id e62sm7637504wma.11.2015.12.14.07.11.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Dec 2015 07:11:16 -0800 (PST) From: Thomas Monjalon To: Jijiang Liu Date: Mon, 14 Dec 2015 16:10:01 +0100 Message-ID: <1610909.TYWkT8rdxQ@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1450079331-28139-1-git-send-email-jijiang.liu@intel.com> References: <1450079331-28139-1-git-send-email-jijiang.liu@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 v3] doc: announce ABI change for struct rte_eth_conf 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: Mon, 14 Dec 2015 15:11:19 -0000 2015-12-14 15:48, Jijiang Liu: > In current codes, tunnel configuration information is not stored in a device configuration, and it will get nothing if application want to retrieve tunnel config, so I think it is necessary to add rte_eth_dev_tunnel_configure() function is to do the configurations including flow and classification information and store it in a device configuration. > > And tunneling packet encapsulation operation will benifit from the change. Sorry, I don't understand what you mean. Maybe others have a clue? > There are more descriptions for the ABI changes below, > > The struct 'rte_eth_tunnel_conf' is a new, its defination like below, > struct rte_eth_tunnel_conf { > uint16_t tx_queue; > uint16_t filter_type; > struct rte_eth_tunnel_flow flow_tnl; > }; > > The ABI change announcement of struct 'rte_eth_tunnel_flow' have already sent out, refer to [1]. > > [1]http://dpdk.org/ml/archives/dev/2015-December/029837.html. > > The change of struct 'rte_eth_conf' like below, but it have not finalized yet. > struct rte_eth_conf { > ... > uint32_t dcb_capability_en; > struct rte_fdir_conf fdir_conf; /**< FDIR configuration. */ > struct rte_intr_conf intr_conf; /**< Interrupt mode configuration. */ > struct rte_eth_tunnel_conf *tunnel_conf[RTE_MAX_QUEUES_PER_PORT]; > /**< Tunnel configuration. */ > }; More generally, is it possible/reasonnable to try saving the whole device configuration in this struct? What is the limit? This rte_eth_conf struct is an input for rte_eth_dev_configure(). Should we add some fields which are not used by rte_eth_dev_configure() but configured through rte_eth_dev_filter_ctrl() instead?