From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v3 07/10] vmxnet3: support jumbo frames Date: Tue, 10 Mar 2015 11:35:59 -0700 Message-ID: <20150310113559.4073f04f@urahara> References: <1425600635-20628-1-git-send-email-stephen@networkplumber.org> <1425600635-20628-8-git-send-email-stephen@networkplumber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" , Stephen Hemminger To: Yong Wang Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On Mon, 9 Mar 2015 23:32:48 +0000 Yong Wang wrote: > > > >I didn=E2=80=99t see where mtu is used to calculate how many rx descript= ors will > >be needed for each packet. Furthermore, as pointed out by the following > >code comments, the device requires the first rx buffer of a packet be of > >type VMXNET3_RXD_BTYPE_HEAD with the remaining buffers of type > >VMXNET3_RXD_BTYPE_NODY. This needs to be taken care of when populating = rx > >rings in vmxnet3_post_rx_bufs(). Currently we don=E2=80=99t do this beca= use no > >scatter-rx is supported and only one descriptor is needed for a packet > >(thus all types should be HEAD). Otherwise, the device will complain wit= h =20 >=20 > To clarify, in this case only the 1st ring will be used and thus all types > will be HEAD. >=20 > >error returned. For the 2nd rx ring, type needs to be BODY for all > >descriptors still. 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. 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. * Buffers are correctly reallocated as needed when consumed. * The code works for bulk transfer and performance tests in jumbo mode. I see no requirement to change this patch. =20