From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [net RFC] net/mlx4_en: Use frag stride in crossing page boundary condition Date: Tue, 19 Jun 2018 17:25:20 -0700 Message-ID: <1bd6da9b-fa46-25e7-8921-cb56eb91e71b@gmail.com> References: <20180614005309.17357-1-saeedm@mellanox.com> <82f89ebc-713c-1b97-0d0a-e455094e2638@gmail.com> <9a8f7e1b2b51320178f671c2ae57d7d54be5af5a.camel@mellanox.com> <1889d389-a741-aa7b-c2b1-14530fb44ba8@gmail.com> <59c3b776cc0c683fff8090195fd71d7f22305744.camel@mellanox.com> <9146b0a3d34388006d456135c9fe4f618260e63b.camel@mellanox.com> <77a87572d82deef1e035ec3b36027e8f6e0c1ea2.camel@mellanox.com> <1ddecaaa-9613-03ba-d761-a4d3410c4f7d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "netdev@vger.kernel.org" , "edumazet@google.com" To: Saeed Mahameed , "eric.dumazet@gmail.com" , "kafai@fb.com" , Tariq Toukan Return-path: Received: from mail-pf0-f194.google.com ([209.85.192.194]:43585 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752915AbeFTAZW (ORCPT ); Tue, 19 Jun 2018 20:25:22 -0400 Received: by mail-pf0-f194.google.com with SMTP id y8-v6so662191pfm.10 for ; Tue, 19 Jun 2018 17:25:22 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 06/19/2018 11:05 AM, Saeed Mahameed wrote: > this is only true for XDP setup, for non XDP max stride_size can only > be around ~3k and only for mtu > ~6k > > For XDP setup you suggested: > - priv->frag_info[0].frag_size = eff_mtu; > + priv->frag_info[0].frag_size = PAGE_SIZE; > > currently the condition is: > > release = frags->page_offset + frag_info->frag_size > PAGE_SIZE; > > so my solution and yours have the same problem you described above. > > the problem is not with the initial values or with stride/farg size > math, it just that in XDP we shouldn't reuse at ALL. I agree with you > that we need to optimize and maybe for PAGE_SIZE > 8k we need to allow > XDP setup to reuses. but for now there is a data corruption to handle. Sure, we all agree there is a bug to fix. The way you are fixing it is kind of illogical. The NIC can use a frag if its _size_ is big enough to receive the frame. The _stride_ is an abstraction created by the driver to report an estimation of the _truesize_, or memory consumption, so that linux can better track overall memory usage. For example, if MTU=1500, the size of the fragment is 1536 bytes, but since we can put only 2 fragments per 4KB page (on x86), we declare the _stride_ to be 2048 bytes. Declaring that a final blob of a page, being 1600 bytes, not able to receive a frame because _stride_ is 2048 is illogical and waste resources.