[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface


  • To: xen-devel@xxxxxxxxxxxxx
  • From: Steven Haigh <netwiz@xxxxxxxxx>
  • Date: Sat, 09 Mar 2013 14:16:32 +1100
  • Delivery-date: Sat, 09 Mar 2013 03:17:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 9/03/2013 1:57 PM, Ian Campbell wrote:
- change MAX_SKB_FRAGS to 19 to accommodate all guests

Changing MAX_SKB_FRAGS is *not* an option upstream. This might be a
useful local hack but we need to drop the idea as a long term fix.

I agree. Its a hack that seems to work until we have something else to offer though. I'll be honest, the internals of the kernel interactions like this is a bit beyond my knowledge - but I get quite a few emails of stuff going strange. This one has increased dramatically in the past week.

Ugh. The negotiations between host and guest is probably the best
choice. The issues you are going to hit are that you might need
to redo the skbs to match what the frontend's max is.

IMHO the right fix is for netback to coalesce as it copies from the
frontend if it needs to do so, it is copying anyway so it should be
cheap enough. I thought we had discussed this and someone was working on
implementing it. If not Annie then perhaps it was Matt or Siva (both now
CC'd)

I did see some talk about it on the xen-devel lists quite some time ago - however it seemed to die with no outcome that I could find. Maybe its a good time for a nudge on the matter :)

If necessary netback could even allocate a larger order head in order to
accommodate very large packets, but I don't expect that to be required
to fix the immediate issue we are seeing (but gives flexibility)

This should get us past the immediate issue of the upstream change from
18->16  frags thing. Longer term the negotiation will allow us to avoid
future incompatible changes in guest and host network stacks, as well as
allowing frontends on other OSes (in particular Windows) to havea better
chance of to DTRT.

Whatever the fix, it has to be on the Dom0 kernel - as stated by others in the past, it isn't a feasible fix to include changes on the client. There would be too many different guest OSes that would make implementation a nightmare - or in fact impossible.

Annie, Wei, Ian - were there some RFC patches floating around
for this?

I didn't stumble across any in the list archives that I hunted for. Not to say they don't exist, but I didn't find them if they do exist.

--
Steven Haigh

Email: netwiz@xxxxxxxxx
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.