From patchwork Mon Sep 10 05:45:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Marchand X-Patchwork-Id: 44462 Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 88CAD1559; Mon, 10 Sep 2018 07:45:54 +0200 (CEST) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id 9131610BD for ; Mon, 10 Sep 2018 07:45:53 +0200 (CEST) Received: by mail-wm0-f66.google.com with SMTP id s12-v6so20149435wmc.0 for ; Sun, 09 Sep 2018 22:45:53 -0700 (PDT) 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; bh=QVudE9bsYQOHVkSTvJ4mCYyM6bUHd4/py26IsTlr/jA=; b=deVx34gZTt1ruHEPG+771CceLTuQbranJ8tJPz3sbkK0KG7T5I1Bu8c6WpXWtPPi6y r02/1KpQNIUdLLn78zZUBJRJBzn0A45bc0410qu+cWki//Smjy0K7mcAWl/mg6sNp+wA Va9RrVX2DGd0Dw4xqs2EXCKQMpw49UA/sJIg2+AZaO+nVreYf/BXV9+vQv11xHJwPBEr KOlv+s7MHNQbYv/CjNPHPW1oq9rKMFuIZck5AeVDY9gn0+Rl2EJaSSPTaeHdeVgL3wdP L/ISGpwBlD8Z6Pq5fK5PptEnysApmclJVZcb01/7Man16G7Ti/2EkBgPc22AVuRCglte FHSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=QVudE9bsYQOHVkSTvJ4mCYyM6bUHd4/py26IsTlr/jA=; b=TvamcS051hUl6OSdvEno5CAxpuMToerFkGhv7C089LGOVUIszjxOZHRtu7zEYqr6G4 BDknHO06ng6MkYNKwELDrMRioXh+QSeOhf3Yo9ZlVVtWcWGlxg4BKeVbWZAc8m7wzCmn g86uMywGcfnfO3yjDYftEas0pMbETK61Fnqc9R12OVe/4Z3DwboVdgCg6o/cysDwpE/d hC6Jt2fX66FI1LOYYm/UQSBJteu255ZuYgatYlZy8eeGHzqzHD5uit2io6BvziSFX5KH xPT0BJHyzToSzq3SyHaQIjp/H+gmr8uBvX0f3biZ28k16TFq/N1GA2fxXYBS5RQm4WOW bAUg== X-Gm-Message-State: APzg51AbBdrGzuABgLQJAjv43sgOefpQ3IJACTdE9jF8BaCWHXUOxAvn SEpN8YTHCsXmeQaHyNgI2exngOlgU9o= X-Google-Smtp-Source: ANB0Vdawf1HcEB7wUT2phdRltRsgrO/ddclwQk9TEUX1SeHReFBUe1nyZ2meZsy9kIJMwPNanPJRCA== X-Received: by 2002:a1c:230f:: with SMTP id j15-v6mr11681201wmj.124.1536558352847; Sun, 09 Sep 2018 22:45:52 -0700 (PDT) Received: from 6wind.com ([109.190.253.16]) by smtp.gmail.com with ESMTPSA id t4-v6sm14667473wrb.45.2018.09.09.22.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Sep 2018 22:45:52 -0700 (PDT) From: David Marchand To: dev@dpdk.org Cc: olivier.matz@6wind.com, wenzhuo.lu@intel.com, jingjing.wu@intel.com, bernard.iremonger@intel.com Date: Mon, 10 Sep 2018 07:45:44 +0200 Message-Id: <20180910054547.18494-1-david.marchand@6wind.com> X-Mailer: git-send-email 2.17.1 Subject: [dpdk-dev] [PATCH 0/3] segment sanity checks 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" Here is a little series which helped me identify a multi segment issue. Hope it can help others. The difference since the RFC patches I sent some time ago is that, rather than force the user to build the dpdk with CONFIG_RTE_LIBRTE_MBUF_DEBUG enabled, it uses rx/tx callbacks to apply checks on the mbufs. This is not perfect, since when an invalid mbuf is detected, we try to free it and a crash is possible at this time (depends on what went wrong). On the rx side, this is better than let this packet go through the application and we end up with harder to identify issues. On the tx side, this is more about validating that the application did not break the mbuf before passing it to the driver. Example: ./testpmd -l 2,14 --socket-mem 2048,0 -w 0000:03:00.0 -w 0000:03:00.1 -- -i [...] testpmd> port stop all testpmd> port config all sanity_check rx+tx testpmd> port config all scatter on testpmd> port start all Configuring Port 0 (socket 0) Port 0: F4:E9:D4:ED:B4:06 Configuring Port 1 (socket 0) Port 1: F4:E9:D4:ED:B4:07 Checking link statuses... Done testpmd> port config mtu 0 9000 testpmd> port config mtu 1 9000 testpmd> start testpmd: invalid rx mbuf on port 1 queue 0: data length too big in mbuf segment testpmd> set verbose 1 Change verbose level from 0 to 1 dump mbuf at 0x7f48db9fa740, iova=2291fa7c0, buf_len=2176 pkt_len=8014, ol_flags=180, nb_segs=4, in_port=1 segment at 0x7f48db9fa740, data=0x7f48db9fa840, data_len=2112 segment at 0x7f48db9fb080, data=0x7f48db9fb180, data_len=2112 segment at 0x7f48db9fb9c0, data=0x7f48db9fbac0, data_len=2112 segment at 0x7f48db9fc300, data=0x7f48db9fc400, data_len=1678 testpmd: invalid rx mbuf on port 1 queue 0: data length too big in mbuf segment