Something odd happened with git-formatpatch here, there was a commit
message originally:
xen/netback: try to pull a minimum of 72 bytes into the skb data area
when receiving a packet into netback. The previous number, 64, tended
to place a fragment boundary in the middle of the TCP header options
and led to unnecessary fragmentation in Windows <-> Windows
networking.
Ian.
On Tue, 2010-02-23 at 16:47 +0000, Ian Campbell wrote:
> From: Steven Smith <ssmith@xxxxxxxxxxxxx>
>
> ---
> drivers/xen/netback/netback.c | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/xen/netback/netback.c b/drivers/xen/netback/netback.c
> index e668704..0bc6398 100644
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -116,13 +116,10 @@ static inline int netif_page_index(struct page *pg)
> /*
> * This is the amount of packet we copy rather than map, so that the
> * guest can't fiddle with the contents of the headers while we do
> - * packet processing on them (netfilter, routing, etc). This could
> - * probably do with being larger, since 1) 64-bytes isn't necessarily
> - * long enough to cover a full christmas-tree ip+tcp header, let alone
> - * packet contents, and 2) the data is probably in cache anyway
> - * (though perhaps some other cpu's cache).
> + * packet processing on them (netfilter, routing, etc). 72 is enough
> + * to cover TCP+IP headers including options.
> */
> -#define PKT_PROT_LEN 64
> +#define PKT_PROT_LEN 72
>
> static struct pending_tx_info {
> struct xen_netif_tx_request req;
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home