From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1073FA00BE; Wed, 27 Apr 2022 21:14:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B3B97410DC; Wed, 27 Apr 2022 21:14:37 +0200 (CEST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by mails.dpdk.org (Postfix) with ESMTP id 3114D40E78 for ; Wed, 27 Apr 2022 21:14:36 +0200 (CEST) Received: by mail-pg1-f170.google.com with SMTP id r83so2198484pgr.2 for ; Wed, 27 Apr 2022 12:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=StElu8ZW0B/tVSefx2L4CL9HUTNuc+TJxtMr7VwoeHk=; b=Btz008nYEkCFYvP6WgqtbeeonhlUSTdudfkxyMxwVXoEBVBZKfOwzCrWkqu42abKHR VQQ4yOJEKXWtk76rf/4gCilz/J7oPB9ppciKDGIpma8PYbTrNZK5qqe611cPh6DMF5mj kn3m1nqq+b2eByVVqO3qpu4u+6CNPkirBVRRnb1Mb8ljLt8zuTYroFXdCjW6IMnoLPUS AeTC/KNtAL6p8Gr7a4FvqUQIdZDcpXr/D1hLykrR6OiTwPPQ83TIPb7W529hLi922VgI Axenq7t8hkuvaw2QlScUmiQcWlmkkYXMXeaHW04esix3KO2vtPnqy8P4aJU+zju2mmz+ hHyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=StElu8ZW0B/tVSefx2L4CL9HUTNuc+TJxtMr7VwoeHk=; b=7V+uDIYEPbwZjcO4pQslCT6yHKocmvehLYATYOUQ7XJxbkI6ZyGiupz0kEbW2ZBX8w CyGbgyS2HvE4KziK+h708ft9K0Eutyj1lTzkqx431T737utjNABnoqxm6mMF6AGMy4xn M1k+Awn62S3sVtKu39ehnAnORqMYKjt3WhB6OZdsbuUY65l5OBpK1FxJHkjaZn9eAqwu JhfV0o78ghk8ztbQkMZ+9JirmoHEWxFR8MWuPnYe9VhxG8YfVHD+MhKMh8e/nAS8/TUy tOpFqmLwJvx+Oqs0A1hUTNb0gtnXUhqxfCEx4hfEx8hUPCwbrEn5f7tRDOiKf59rhzL8 a8sQ== X-Gm-Message-State: AOAM530I0LngS1k32kmF3J90KBbowiCn/CzHU79xV71blMlEHrpZu5pC 1he+XMQFp0PVVtkSiq/0Tb0XMA== X-Google-Smtp-Source: ABdhPJwbHOjpAe6azQYln2ecRGVksmNUMSEEYNLk4OJuxWd5Eu+ELX3gbkugjHapCkxka2LW/mKeNg== X-Received: by 2002:a05:6a00:814:b0:50d:450a:dc5e with SMTP id m20-20020a056a00081400b0050d450adc5emr15394759pfk.15.1651086875168; Wed, 27 Apr 2022 12:14:35 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id b1-20020a631b41000000b003c14af50631sm61506pgm.73.2022.04.27.12.14.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 12:14:34 -0700 (PDT) Date: Wed, 27 Apr 2022 12:14:32 -0700 From: Stephen Hemminger To: Ido Goshen Cc: Ferruh Yigit , "dev@dpdk.org" , Danny Raveh Subject: Re: [PATCH] net/pcap: support MTU set Message-ID: <20220427121432.5dc81957@hermes.local> In-Reply-To: References: <20220317174347.110909-1-ido@cgstowernetworks.com> <20220317112047.2d8d4f8a@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 27 Apr 2022 18:21:37 +0000 Ido Goshen wrote: > > From: Ferruh Yigit > > Sent: Tuesday, 26 April 2022 20:04 > >=20 > > On 3/22/2022 1:02 PM, Ido Goshen wrote: =20 > > > This test > > > https://doc.dpdk.org/dts/test_plans/jumboframes_test_plan.html#test-ca > > > se-jumbo-frames-with-no-jumbo-frame-support fails for pcap pmd Jumbo > > > packet is unexpectedly received and transmitted > > > =20 > >=20 > > Hi Ido, > >=20 > > Yes, pcap ignores MTU, but I don't see why it should use MTU (except fr= om > > making above DTS test pass). > >=20 > > For the cases packets written to .pcap file or read from a .pcap file, = most > > probably user is interested in all packets, I don't think using MTU to = filter the > > packets is a good idea, missing packets (because of MTU) can confuse us= ers. =20 >=20 > [idog]=20 > receiving/sending unexpected packets may be confusing too (it is subjecti= ve) > The rx-err counter should clarify it. More advanced PMDs also have a rx_o= versize counter=20 > but this will require xstats which seems an overkill. > It is also out of bound memory access prone if app is not expecting segme= nted mbufs and=20 > refers to data within mbuf->pkt_len which is beyond the 1st segment mbuf-= >data_len >=20 > As is there is no control, packets will pass whether one likes it or not > This patch provides the control. > If the current behaviour (not to drop) seems better then it can become th= e default > i.e. auto set the initial mtu to 9K or 16K >=20 > >=20 > > Unless there is a good use case, I am for rejecting this feature. =20 >=20 > [idog]=20 > The main use case is for testing, which is probably the main reason for p= cap pmd.=20 > We support jumbo and mtu in our products but our pcap based CI tests cann= ot cover it. > We also have a SW pcap based simulator which we=E2=80=99d like to behave = the same as possible > as our HW products. > Is there a good reason that pcap pmd will behave different then other pmd= s? Why not use existing tools to filter the pcap file before you feed it to CI= tests? Other drivers may (or may not) receive packets greater than MTU. It is real= ly driver and hardware dependent.