From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter01.viettel.com.vn (mailfilter01.viettel.com.vn [125.235.240.53]) by dpdk.org (Postfix) with ESMTP id E62201B59C for ; Thu, 10 Jan 2019 04:25:51 +0100 (CET) DomainKey-Signature: s=dmsig1; d=viettel.com.vn; c=simple; q=dns; h=Authentication-Results:X-IronPort-AV:Received:Received: Received:Received:X-Virus-Scanned:Received:Received:To:Cc: References:In-Reply-To:Subject:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:X-Mailer: Thread-Index:Content-Language:MilterAction:Date:From; b=piEAz/IkWnV826owDc7zawwS+R3+OGytJNIhqXd8NKL1IFoQ1EugJB7N e5cZv9j32PyrXBCO/PUAlPsI+69Ag3pzLKB75GdcnkL8T/96aQXjF/7aH jk9bmmbaeNQe6UcBLgEfXuhQ+5Yr2V6pgQtHv84JGsWQWQnGTou3EioXm WpRi6nUglZF38+dH+Ap4SuHk2MOJrP1BVsYgPZxt1q8n7FD6qNWpAwuhI nYVNFaMHVHMyvGqaO3i5P0590pw0SQRyYLKbwO/QCGGi6/kox+uWZ8AoS Al1GB/qR/CrO/4kcIOWiWVD5wTT5++CSz29+0iZdaVVJkBXFX+tGSzKvT w==; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=viettel.com.vn; s=dkim1; t=1547090752; h=to:cc:references:in-reply-to:subject:message-id: mime-version:content-transfer-encoding:date:from; bh=suNtPYpWDETMq2UGIn43uTtwezv9S5eyf9RQr+Ma550=; b=dF9i70Otkw0CclB7zqnTZ/3a6eNODCtyxECO3l41wNL5xHno+okTpCaF LykeyU7jGvNQVAEqz0zDMCCZQrlvhB/rpIDGQwYarJLVvCATgdDS1SrD9 6TMTX/ZNJAjxUx27dQ/QiAxGBtXZXkWeKXuFRMzLYqdjiwigGmsNIZAuY gP/n1nHV8jQvkrUtMmm2MaCVFnFwziCCNQtWVerAVsBcanjyDSvs4NPbn VNdabQPKMt2XPYltlugW45Q6vFP0bk4cVLm1AuUTJ/IhrZcypTYxB+YBx LUktGpSRu3lwL0bNqjEZGbAHwGXfNBZK2VegRk/9Au2oCR5XRZpNiQbp+ w==; Authentication-Results: mailfilter01.viettel.com.vn; spf=Pass smtp.mailfrom=longtb5@viettel.com.vn; dmarc=pass (p=none dis=none) d=viettel.com.vn X-IronPort-AV: E=Sophos;i="5.56,253,1539622800"; d="scan'208";a="120276306" Received: from 125.235.240.45.adsl.viettel.vn (HELO mta2.viettel.com.vn) ([125.235.240.45]) by mailfilter01.viettel.com.vn with ESMTP; 10 Jan 2019 10:25:48 +0700 Received: from localhost (localhost [127.0.0.1]) by mta2.viettel.com.vn (Postfix) with ESMTP id 7E58968919D; Thu, 10 Jan 2019 10:25:40 +0700 (ICT) Received: from mta2.viettel.com.vn ([127.0.0.1]) by localhost (mta2.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YKJccpZc_9fx; Thu, 10 Jan 2019 10:25:40 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta2.viettel.com.vn (Postfix) with ESMTP id 59BD26891AC; Thu, 10 Jan 2019 10:25:40 +0700 (ICT) X-Virus-Scanned: amavisd-new at Received: from mta2.viettel.com.vn ([127.0.0.1]) by localhost (mta2.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JXNIfZVRrnHf; Thu, 10 Jan 2019 10:25:40 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta2.viettel.com.vn (Postfix) with ESMTPSA id 106D66891A8; Thu, 10 Jan 2019 10:25:40 +0700 (ICT) To: , , "'Olivier Matz'" Cc: References: <002301d4a7ce$d095b240$71c116c0$@viettel.com.vn> <98CBD80474FA8B44BF855DF32C47DC35B425B7@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425B7@smartserver.smartshare.dk> Message-ID: <000001d4a895$85ffbbf0$91ff33d0$@viettel.com.vn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFUhd/JDcKPVtRg3YVKekdHyQH2IQK80cwRppI2haA= Content-Language: en-us MilterAction: FORWARD Date: Thu, 10 Jan 2019 10:25:40 +0700 (ICT) From: longtb5@viettel.com.vn Subject: Re: [dpdk-dev] [RFC] function to parse packet headers 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: , X-List-Received-Date: Thu, 10 Jan 2019 03:25:53 -0000 Also for the bulk API, another option would be passing in a `uint64_t = malformed_mask` and let the bulk function set the correspond bit (1 << = pos) of that mask if the packet at position pos is malformed. void rte_hdr_parse_bulk(struct rte_mbuf **pkts, uint64_t = *malformed_mask, uint_fast16_t nb_pkts); The packet mask idea is used extensively in the packet framework = (rte_pipeline, rte_port, rte_table). > -----Original Message----- > From: mb@smartsharesystems.com [mailto:mb@smartsharesystems.com] > Sent: Wednesday, January 9, 2019 10:39 PM > To: longtb5@viettel.com.vn; roszenrami@gmail.com; Olivier Matz > > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [RFC] function to parse packet headers >=20 > Cutting in Olivier, requesting input as the maintainer of rte_net. >=20 > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of > > longtb5@viettel.com.vn > > > > Hi Morten, > > > > What is the difference compare to rte_net_get_ptype(), which also > > parses packet types and reports on header length. > > > > In my application I have also done something similar about malformed > > packets. IMO it's very useful to have return value indicate = different > > types of malformed packets, not just -1, e.g. invalid IP options, IP > > loopback, etc. >=20 > They are very similar. The main differences are: > - The header length fields are set in the MBUF, not returned in a = separate > structure. This would only be relevant for a bulk function. > - In theory, it would be possible to set the length fields without = accessing the > packet data, but just by looking at MBUF->packet_type for some = packets; > e.g. RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4 | RTE_PTYPE_L4_UDP is > quite common due to Google's QUIC protocol (and will be with the = coming > HTTP/3 protocol). > - Testing for malformed packets, e.g. a length field suggesting that = the packet > is longer than it actually is, or a header length field suggesting = that the header > is shorter than the header's structure. (This obviously requires = accessing the > packet data, which makes the above point about not accessing the = packet > data irrelevant.) >=20 > It might be better to extend rte_net_get_ptype() by adding checks for > malformed packets, rather than introducing an almost similar function. >=20 > And then the bulk function could use rte_net_get_ptype(). >=20 > > > > Regards, > > BL