From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 7D7B32BF1 for ; Thu, 22 Jun 2017 18:00:27 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 22A3820BFD; Thu, 22 Jun 2017 12:00:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 22 Jun 2017 12:00:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=yzzCSFYzV1LDq6E 3KBMXbrNPP+GzHVzp8mQceujQrEw=; b=O07es8tRpIJ9EjLg8RJpNM4CX/3nwe9 bBFs3MRFBGy++jFBkQ85z22dWbpljh/RG9vImEHY7lyUMFhutfL7/D2uSiQfkmI6 EIrHgDGb9hOFc23X7hnyl1uG8WkIqtLE8xGUKqI/dlEUxA1PjFDZVA2kiEBVUZZr v0p0AOTU26NI= 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=yzzCSFYzV1LDq6E3KBMXbrNPP+GzHVzp8mQceujQrEw=; b=SUwabLrW PhR993uSHa9FzIyvh7lYQcQ0bizNEWG6h0p3wWoXLVQZ/MWcFAPyr4Byys0Kwk9c F6sxEbE1VQEat3ig8UK+kuOMoug/SWsLl/YerpXBpaJH2+s7R7qZdzMW8aIsUku2 loZTvq1OabTu+TIe2QMXxXal4j+x0oP5SpGsbYy3IoBwvKWFAx1s5QyBP15B7ihj X7QVD1GBmP+533eWG6rmtacETmIDVMABJeOhLgfs/cIs4wKKYSucUlgjOfZp7pq/ rbw65775XpT9UFfMsCIOClvroxAXo+7kJwe22K7/+vi6cdpGco/+mduITZZz412r FDkQU16IKLJ+bQ== X-ME-Sender: X-Sasl-enc: JUxkPJPTTOsiE8T2tuTruzrGE0Ed7vLGPvoinyY2ni/1 1498147226 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CBCFF24038; Thu, 22 Jun 2017 12:00:26 -0400 (EDT) From: Thomas Monjalon To: "Legacy, Allain (Wind River)" Cc: dev@dpdk.org, "Ananyev, Konstantin" Date: Thu, 22 Jun 2017 18:00:25 +0200 Message-ID: <3344778.x1AQTSzbEx@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB058D0@IRSMSX109.ger.corp.intel.com> References: <1489504487-67456-1-git-send-email-allain.legacy@windriver.com> <2601191342CEEE43887BDE71AB9772583FB058D0@IRSMSX109.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] ip_frag: handle MTU sizes not aligned to 8 bytes 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, 22 Jun 2017 16:00:27 -0000 > > The rte_ipv4_fragment_packet API expects that the link/interface MTU value > > passed in be divisible by 8 bytes. Given the name of the parameter is > > "mtu" rather than "frag_size" it is not necessarily the case that it will > > be divisible by 8. An MTU of 1500 happens to produce a max fragment size > > of 1480 (1500 - sizeof(ipv4_hdr)) which is divisible by 8 but other MTU > > values such as 1600 or 9000 do not produce values that are divisible by 8. > > > > Unfortunately, the API checks that the frag_size value produced is > > divisible by 8 with a call to RTE_ASSERT which is only enabled when the > > RTE_LOG_LEVEL >= RTE_LOG_DEBUG. In cases where the log level is set > > normally the code silently continues and produces IP fragments that have > > invalid fragment offset values. > > > > An application may not have control over what MTU a user selects and rather > > than have each application adjust the MTU to pass a suitable value to the > > fragmentation API this change modifies the fragmentation API to handle > > cases where the "mtu" argument is not divisible by 8 and automatically > > adjust the internal "frag_size". > > > > Signed-off-by: Allain Legacy > > Acked-by: Konstantin Ananyev Applied, thanks