From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 897E5A00E6 for ; Thu, 18 Apr 2019 17:51:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DD0D11BBF8; Thu, 18 Apr 2019 17:51:22 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 505031BBF4; Thu, 18 Apr 2019 17:51:21 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E62A327875; Thu, 18 Apr 2019 11:51:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 18 Apr 2019 11:51:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=FHjps8cvj6Ut1bw0QB68py9u3DEGb8GWxIG2OQ47lJs=; b=bATKvhPrUQIq t46mafXdA/4Gif0BZxPBheu13vXbvayx8FxVA4+PlsyEJc6oQtI49jxxDXn/1xKf RWkYaMajFY0+JIlIOAa0MPlmOiZJZ82vaa351B7nworkrujqt+QB5DZxnDG5o2AC UtEEALtabC8mSjmg5jZs7yIGTlxwdYo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=FHjps8cvj6Ut1bw0QB68py9u3DEGb8GWxIG2OQ47l Js=; b=x0wOOXrwT8Ta/O6XiHULXwFEAV5tpf8HMvg0JsKRLXaOSgh+8lTjgjdkY QEf0ZMylE+pN0i1WZTrnKZOAV72IExMzJHnyuDHGU4a7YCqbV0LiZJsxSDnCcsnh JMJSGXuscfEsjpLqeucRblLKtqvzk+KOSd/DJNbmotJ+ZsRFB4+Mu084zh2Vd6Uz 5T4HH/I+xM6DGHqtMRNtmGhDive+9DLi/9lYOy5JBVDSvOVDTu13vTDzWKKmgCT4 UdjuNMBSWd1mqo7bcGK9qepBK3CL+RuVblMWpBRRCarmN5l+cVYcamebbuGtp+vw cYAbwNOBqxgWtaYaEx7ws22De34/Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrfeehgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DA9F103CC; Thu, 18 Apr 2019 11:51:19 -0400 (EDT) From: Thomas Monjalon To: Adrien Mazarguil Cc: dev@dpdk.org, Gaetan Rivet , Ferruh Yigit , David Marchand , stable@dpdk.org Date: Thu, 18 Apr 2019 17:51:18 +0200 Message-ID: <2732210.eFvFzSlaYO@xps> In-Reply-To: <8815526.EAVJVpUmGC@xps> References: <20190418130419.25675-1-adrien.mazarguil@6wind.com> <20190418152229.13554-1-adrien.mazarguil@6wind.com> <8815526.EAVJVpUmGC@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2] net/failsafe: fix source port ID in Rx packets X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190418155118.1vPdaFyhtwBL7fXkU6A_f0P1XcGLBAeSWrpFO1EOwno@z> 18/04/2019 17:39, Thomas Monjalon: > 18/04/2019 17:32, Adrien Mazarguil: > > When passed to the application, Rx packets retain the port ID value > > originally set by slave devices. Unfortunately these IDs have no meaning to > > applications, which are typically unaware of their existence. > > > > This confuses those caring about the source port field in mbufs (m->port) > > which experience issues ranging from traffic drop to crashes. [...] > > +/* > > + * Override source port in Rx packets. > > + * > > + * Make Rx packets originate from this PMD instance instead of one of its > > + * slaves. This is mandatory to avoid breaking applications. > > + */ > > +static void > > +failsafe_rx_set_port(struct rte_mbuf **rx_pkts, uint16_t nb_pkts, uint16_t port) > > +{ > > + unsigned int i; > > + > > + for (i = 0; i != nb_pkts; ++i) > > + rx_pkts[i]->port = port; > > +} > > + > > uint16_t > > failsafe_rx_burst(void *queue, > > struct rte_mbuf **rx_pkts, > > @@ -87,6 +102,9 @@ failsafe_rx_burst(void *queue, > > sdev = sdev->next; > > } while (nb_rx == 0 && sdev != rxq->sdev); > > rxq->sdev = sdev; > > + if (nb_rx) > > + failsafe_rx_set_port(rx_pkts, nb_rx, > > + rxq->priv->data->port_id); > > return nb_rx; > > } > > I'm afraid the performance drop to be hard. > How the port id in mbuf is used exactly? What crash are you seeing? Another way to fix it without performance drop would be to add a new driver op to set the top-level port id. This top-level id would be stored in the private structure of the port, initialized with the port id of the port itself, and used to fill mbufs. Thoughts?