From mboxrd@z Thu Jan 1 00:00:00 1970 From: ANNIE LI Subject: Re: netchannel vs MAX_SKB_FRAGS (Was: Re: [PATCH] xen/netfront: handle compound page fragments on transmit) Date: Fri, 23 Nov 2012 14:49:41 +0800 Message-ID: <50AF1C85.50604@oracle.com> References: <1353403286.18229.159.camel@zakaz.uk.xensource.com> <1353411606-15940-1-git-send-email-ian.campbell@citrix.com> <50AB856D02000078000A9EFD@nat28.tlf.novell.com> <1353418516.13542.38.camel@zakaz.uk.xensource.com> <50AB990602000078000A9F5B@nat28.tlf.novell.com> <1353420865.13542.44.camel@zakaz.uk.xensource.com> <50ABA29902000078000A9FB1@nat28.tlf.novell.com> <1353424014.13542.49.camel@zakaz.uk.xensource.com> <1353425308.2590.11.camel@edumazet-glaptop> <1353426878.13542.59.camel@zakaz.uk.xensource.com> <1353427456.13542.65.camel@zakaz.uk.xensource.com> <50AED1A8.30607@oracle.com> <6035A0D088A63A46850C3988ED045A4B32C95411@BITCOM1.int.sbss.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6035A0D088A63A46850C3988ED045A4B32C95411@BITCOM1.int.sbss.com.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: James Harper Cc: KonradRzeszutekWilk , Ian Campbell , xen-devel List-Id: xen-devel@lists.xenproject.org On 2012-11-23 10:10, James Harper wrote: >> On 2012-11-21 0:04, Ian Campbell wrote: >>> Limiting to just xen-devel folks. >>> >>> On Tue, 2012-11-20 at 15:54 +0000, Ian Campbell wrote: >>> >>> This highlights a couple of issues, the main one is that implicitly >>> including MAX_SKB_FRAGS in the PV net protocol is just madness. It can >>> and has changed in the past. Someone really needs to (retroactively) >>> figure out what a sensible default minimum which front and back must >>> support is and use it in the front and backends instead of >>> MAX_SKB_FRAGS. Probably something derived from the existing 64K limit >>> (Linux has used 17 and 18 as MAX_SKB_FRAGS in the past). >>> >>> Then perhaps implement a feature-flag to allow front and backends to >>> negotiate something bigger if they like. >>> >>> It might also be interesting for front and backends to coalesce >>> multiple ring slots into compound pages. >> Yes, MAX_SKB_FRAGS is max frag number, not max slot number required. >> But I am not so clear about the whole implementation here. Does it mean >> netfront/netback uses something like MAX_SKB_FRAGS*SLOTS_PER_FRAG? >> and SLOTS_PER_FRAG can be adjusted based on different situation? If >> netfront and netback negotiate this value, then xenstore key feature is >> required, right? >> As mentioned in another compound page fragments patch, for non- >> compound page, this value could be 64K/PAGE_SIZE + 1, but if taking account >> into compound page, the worse case is around 48 slots(in 1+4096+1 case). It >> is hard to negotiate this between netfront and netback for different packets. >> > FWIW, Windows appears to have no real limit in its SG list, and if its>18 then netback (or linux?) just drops such packets. This should be netback dropping packets in function netbk_count_requests, if (unlikely(frags >= MAX_SKB_FRAGS)) { netdev_dbg(vif->dev, "Too many frags\n"); return -frags; } > For a 64kb "large" packet, the buffer arrangement would likely be eth hdr + ip hdr + tcp hdr + (64K - total header size)/PAGE_SIZE + 1 frags. It would be good if the documentation of the protocol defined this limitation (which may not even exist if dom0 was something other than Linux anyway). Agree. Thanks Annie > > James > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel