http://bugzilla.suse.com/show_bug.cgi?id=1104824
http://bugzilla.suse.com/show_bug.cgi?id=1104824#c2
--- Comment #2 from Jürgen Groß
As the problem only occurs when the first fragment is larger than the RX_COPY_THRESHOLD, I had the idea to enlarge RX_COPY_THRESHOLD to the maximum size of a fragment:
#define RX_COPY_THRESHOLD 4096
There is no explanation in the source code why RX_COPY_THRESHOLD is only 256 at the moment. May be someone can explain.
I guess the main problem with setting RX_COPY_THRESHOLD to 4096 is that allocation of each RX buffer needs more than one page of memory. Only with RX_COPY_THRESHOLD smaller than 3776 bytes (PAGE_SIZE - sizeof(struct skb_shared_info)) one page will be able to hold the needed data.
However, my first tests with the enlarged value of 4096 were successful and free of side effects.
I guess with some memory pressure and long system-up times the picture might change. I'm looking at two possible approaches in the moment: Either I'd like to set the max number of slots depending on the backend version (for old backends one less than for new backends), but I guess this is a rather fragile solution. What I would like better is to replace the BUG_ON() in xennet_fill_frags() with a way to fail the receive operation gracefully. This could be made less probable by upping RX_COPY_THRESHOLD to a value like above mentioned 3776. -- You are receiving this mail because: You are on the CC list for the bug.