From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by dpdk.org (Postfix) with ESMTP id 2511B9A96 for ; Wed, 11 Mar 2015 07:54:17 +0100 (CET) Received: by paceu11 with SMTP id eu11so9001478pac.1 for ; Tue, 10 Mar 2015 23:54:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=0NP9BcswcqjuESKBizI/Q7uOyH0yMBVM3nDhNOtJE/c=; b=gcLIjVANGKE6ShjI3VFEhPQSLTSZy2yMmnMMjYN5jY4Xu5xk1TE6gZsZFYkUg/8SC9 RxlQfIe+JgKYRLNi6NVKsx5HcHXYViOCfMKK0Tcq7err3cmv5bbqQ4WYMG9j3fyWbHAm VGQEQxhUyBC2lsS4H3EVSMgpqeQxAY/mc3yIGyIlhytMJT8dhJgPi2lC03zEUXtftUT9 1X0lWJJvdpuOTGXsanGjeJFfm2uX5xU2Ft0S3Q6oFivUBKqyLNo/edSPzo0lcM+vwrv3 0FuZjHgP1t2FkrO5TgdhqsEhZ1dJ3HIYKSrP0lgZnOBtRhPeeZTTU9ZqaQfPHWe7axEu bJjw== X-Gm-Message-State: ALoCoQnHd4VkXTQOnqpdU5vCHuNv0bm2wiwuXLUzY6ogNhUTpFgpWI7RqiGC63AisadoQnwULwX6 X-Received: by 10.66.141.231 with SMTP id rr7mr70221910pab.72.1426056856254; Tue, 10 Mar 2015 23:54:16 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id ji6sm4261974pac.30.2015.03.10.23.54.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 23:54:15 -0700 (PDT) Date: Tue, 10 Mar 2015 23:54:11 -0700 From: Stephen Hemminger To: Yong Wang Message-ID: <20150310235411.0ec554d2@urahara> In-Reply-To: <4ebc1312d5cb42d583fb8a204c353feb@BRMWP-EXMB11.corp.brocade.com> References: <1425600635-20628-1-git-send-email-stephen@networkplumber.org> <1425600635-20628-8-git-send-email-stephen@networkplumber.org> <20150310113559.4073f04f@urahara> <4ebc1312d5cb42d583fb8a204c353feb@BRMWP-EXMB11.corp.brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , Stephen Hemminger Subject: Re: [dpdk-dev] [PATCH v3 07/10] vmxnet3: support jumbo frames X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 06:54:17 -0000 On Wed, 11 Mar 2015 01:03:37 +0000 Yong Wang wrote: > >Looking in more detail, the code as submitted looks fine: > > > >* The # of rx descriptors needed for each packet is responsibility of > > the application. Before and after this patch the # of Rx descriptors > > for each ring (head/body) is determined by vmxnet3_rx_queue_setup. > > And the driver always allocates the same number of descriptors > > for both Rx rings. =20 >=20 > Where is vmxnet3_rx_queue_setup? It=E2=80=99s not in the current code bas= e nor in > your patch and I failed to see how rx descriptors are populated. > Could you explain what do you mean by responsibility of the application? > If mtu is set to 9000, the driver needs to make sure rx buf per packet is > set to the correct size with proper type set, right? vmxnet3_dev_rx_queue_setup is unchanged from original Intel code. But you are right there is a bug there since it will error out if max_rx_pkt_len > bufsize. That error check should have been removed. That was an oversight from the merge of our code with the DPDK/Intel code. Just removing the check and surrounding code is all that is necessary. After that driver will receive scattered mbufs. None of the DPDK drivers do a good job of checking all the possible misconfiguration of rxmode, jumbo and scattered flags. There is room for improvement in all drivers around that. > > One could argue that was a bug in the original driver, since it > >needlessly > > allocated mbufs for the second ring and never used them. I suppose > > as a optimization in future, the second ring could be sized as 0 > > and no buffers allocated unless doing rx-scatter (this is what the > > Linux driver does. But that change is independent of this. =20 >=20 > We can just keep it as is as we will need it if someone decides to support > LRO for vmxnet3. But LRO must be optional since LRO is broken for the case of forwarding. Linux driver handles the case of only allocating second ring if necessary. Although the Linux vmxnet3 driver was broken about LRO setting for several years, it is fixed now. > > > >* Buffers are correctly reallocated as needed when consumed. > > > >* The code works for bulk transfer and performance tests in jumbo mode. = =20 >=20 > You mean the standalone patch you posted without the > vmxnet3_rx_queue_setup you mentioned? The code in recv that calls vmxnet3_post_rx_bufs works for both rings already. It was just until the scattered logic was engaged the second ring was never used.