WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Xen

xen-devel

[Top] [All Lists]

Re: [Xen-devel] [0/5] [NET]: Add TSO support

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [0/5] [NET]: Add TSO support
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: 2006年6月29日 14:20:21 +0100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: 2006年6月29日 06:27:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060629124614.GA21911@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060627120240.GA748@xxxxxxxxxxxxxxxxxxx> <4ce42ba97df34accef8d150fbbe251f4@xxxxxxxxxxxx> <20060628140239.GA9248@xxxxxxxxxxxxxxxxxxx> <d963f536d9918d951418dcf1b935d1d9@xxxxxxxxxxxx> <20060629002020.GA16348@xxxxxxxxxxxxxxxxxxx> <390960d535dacfea77754357cf9cc55e@xxxxxxxxxxxx> <20060629094045.GA20816@xxxxxxxxxxxxxxxxxxx> <bc12b2d3847b6c6d03668954b8f3d25c@xxxxxxxxxxxx> <20060629124614.GA21911@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 29 Jun 2006, at 13:46, Herbert Xu wrote:
What if gso_segs, or any other gso parameter (e.g., type), is set
incorrectly? The backend cannot trust frontend clients, so I'm rather
worried that we could make the backend network stack crash!
gso_type is a key so the OS (Linux) must deal with all possible values.
Any packet with a protocol or feature bit that it does not recognise
will be dropped.
However, you have a very good point regarding gso_segs. I'll change it
so that it is always recalculated for SKB_GSO_DODGY packets.
If you can recalculate it, why is the field required at all (both in the skbuff and in the netif_tx_extra)? You previously said it was needed because it can't be recalculated (until you get to the segmentation code, which may be very late in packet processing). We could calculate gso_segs for TCPv4 in netback, which is all we care about right now.
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] Re: [PATCH][ACM][UPDATE] python tools and support for resource labeling , Ewan Mellor
Next by Date: Re: [Xen-devel] [0/5] [NET]: Add TSO support , Herbert Xu
Previous by Thread: Re: [Xen-devel] [0/5] [NET]: Add TSO support , Herbert Xu
Next by Thread: Re: [Xen-devel] [0/5] [NET]: Add TSO support , Herbert Xu
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /