Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove unconditional __pskb_pull_tail() in guest Tx path

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: annie li [mailto:annie.li@xxxxxxxxxx]
> Sent: 05 November 2014 19:02
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxxxxxxxxx; Malcolm Crossley; Wei Liu;
> David Vrabel
> Subject: Re: [Xen-devel] [PATCHv2 net-next] xen-netback: remove
> unconditional __pskb_pull_tail() in guest Tx path
> 
> 
> On 2014/11/5 6:24, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Ian Campbell
> >> Sent: 05 November 2014 11:20
> >> To: Paul Durrant
> >> Cc: David Vrabel; xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu; Malcolm
> Crossley
> >> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> >> __pskb_pull_tail() in guest Tx path
> >>
> >> On Wed, 2014-11-05 at 11:17 +0000, Paul Durrant wrote:
> >>>> -----Original Message-----
> >>>> From: Ian Campbell
> >>>> Sent: 05 November 2014 11:00
> >>>> To: David Vrabel
> >>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu; Malcolm Crossley; Paul
> >> Durrant
> >>>> Subject: Re: [PATCHv2 net-next] xen-netback: remove unconditional
> >>>> __pskb_pull_tail() in guest Tx path
> >>>>
> >>>> Dropping netdev since this isn't relevant to them, adding Paul
> >>>>
> >>>> On Wed, 2014-11-05 at 10:50 +0000, David Vrabel wrote:
> >>>>> - performance: Netback has already grant copied up-to 128 bytes
> from
> >>>>>    the first slot of a packet into the linear area. The first slot
> >>>>>    normally contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>> Does "normally" include guests other than Linux? I thought Windows in
> >>>> particular was prone to splitting the headers into a frag per layer or
> >>>> thereabouts?
> >>>>
> >>> Current upstream Windows PV drivers will put all parsed headers in the
> >>> first frag and the rest of the packet in subsequent flags. The parser
> >>> currently knows about TCP and UDP over IPv4 or v6, with and without
> >>> SNAP encapsulation. It doesn't, for example, know about ARP so the
> >>> backend will see only the ethernet header in the first frag.
> >> Sounds like that is sufficient to reach the "normally" qualification,
> >> thanks.
> >>
> >> (I wonder what sort of benefit parsing arp would bring...)
> >>
> > Previous versions of the drivers used to parse ARPs so that copies of
> outgoing gratuitous ARPs could be cached for replay after migrate. Newer
> drivers acquire IP address bindings from the Windows IP helper (which is
> now available in kernel) and synthesize ARPs/IPv6 neighbour solicitations.
> I send out fake ARP after migration to deal with it, guess you are
> mentioning here
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/ff557015(v=vs.85).aspx
> ? which is available for kernel later than Vista.
> 

Yes. The upstream PV drivers are Vista+ only.

  Paul

> Thanks
> Annie

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