Comment # 2 on bug 1104824 from J�rgen Gro�

(In reply to Manfred H�rtel from comment #1)
> 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.