From patchwork Wed Jul 11 18:23:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Lam, Tiago" X-Patchwork-Id: 942625 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=intel.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41QncZ23WMzB4MY for ; Thu, 12 Jul 2018 04:27:58 +1000 (AEST) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 90A19F22; Wed, 11 Jul 2018 18:24:02 +0000 (UTC) X-Original-To: ovs-dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DC641F0C for ; Wed, 11 Jul 2018 18:23:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6FAF2777 for ; Wed, 11 Jul 2018 18:23:59 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 11:23:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,338,1526367600"; d="scan'208";a="71504445" Received: from silpixa00399125.ir.intel.com ([10.237.223.34]) by fmsmga001.fm.intel.com with ESMTP; 11 Jul 2018 11:23:58 -0700 From: Tiago Lam To: ovs-dev@openvswitch.org Date: Wed, 11 Jul 2018 19:23:35 +0100 Message-Id: <1531333421-235225-9-git-send-email-tiago.lam@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1531333421-235225-1-git-send-email-tiago.lam@intel.com> References: <1531333421-235225-1-git-send-email-tiago.lam@intel.com> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: i.maximets@samsung.com Subject: [ovs-dev] [PATCH v5 08/14] dp-packet: Handle multi-seg mbufs in resize__(). X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org When enabled with DPDK OvS relies on mbufs allocated by mempools to receive and output data on DPDK ports. Until now, each OvS dp_packet has had only one mbuf associated, which is allocated with the maximum possible size, taking the MTU into account. This approach, however, doesn't allow us to increase the allocated size in an mbuf, if needed, since an mbuf is allocated and initialised upon mempool creation. Thus, in the current implementatin this is dealt with by calling OVS_NOT_REACHED() and terminating OvS. To avoid this, and allow the (already) allocated space to be better used, dp_packet_resize__() now tries to use the available room, both the tailroom and the headroom, to make enough space for the new data. Since this happens for packets of source DPBUF_DPDK, the single-segment mbuf case mentioned above is also covered by this new aproach in resize__(). Signed-off-by: Tiago Lam Acked-by: Eelco Chaudron --- lib/dp-packet.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/lib/dp-packet.c b/lib/dp-packet.c index d6e19eb..87af459 100644 --- a/lib/dp-packet.c +++ b/lib/dp-packet.c @@ -237,9 +237,51 @@ dp_packet_resize__(struct dp_packet *b, size_t new_headroom, size_t new_tailroom new_allocated = new_headroom + dp_packet_size(b) + new_tailroom; switch (b->source) { + /* When resizing mbufs, both a single mbuf and multi-segment mbufs (where + * data is not contigously held in memory), both the headroom and the + * tailroom available will be used to make more space for where data needs + * to be inserted. I.e if there's not enough headroom, data may be shifted + * right if there's enough tailroom. + * However, this is not bulletproof and in some cases the space available + * won't be enough - in those cases, an error should be returned and the + * packet dropped. */ case DPBUF_DPDK: - OVS_NOT_REACHED(); + { + size_t miss_len; + + if (new_headroom == dp_packet_headroom(b)) { + /* This is a tailroom adjustment. Since there's no tailroom space + * left, try and shift data towards the head to free up tail space, + * if there's enough headroom */ + + miss_len = new_tailroom - dp_packet_tailroom(b); + + if (miss_len <= new_headroom) { + dp_packet_shift(b, -miss_len); + } else { + /* XXX: Handle error case and report error to caller */ + OVS_NOT_REACHED(); + } + } else { + /* Otherwise, this is a headroom adjustment. Try to shift data + * towards the tail to free up head space, if there's enough + * tailroom */ + + miss_len = new_headroom - dp_packet_headroom(b); + + if (miss_len <= new_tailroom) { + dp_packet_shift(b, miss_len); + } else { + /* XXX: Handle error case and report error to caller */ + OVS_NOT_REACHED(); + } + } + + new_base = dp_packet_base(b); + + break; + } case DPBUF_MALLOC: if (new_headroom == dp_packet_headroom(b)) { new_base = xrealloc(dp_packet_base(b), new_allocated); @@ -263,7 +305,9 @@ dp_packet_resize__(struct dp_packet *b, size_t new_headroom, size_t new_tailroom OVS_NOT_REACHED(); } - dp_packet_set_allocated(b, new_allocated); + if (b->source != DPBUF_DPDK) { + dp_packet_set_allocated(b, new_allocated); + } dp_packet_set_base(b, new_base); new_data = (char *) new_base + new_headroom;