[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: skb_checksum_setup() placement in pv-ops vs. legacy kernel



>>> On 03.12.10 at 12:12, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Fri, 2010-12-03 at 10:52 +0000, Jan Beulich wrote:
>> Ian, Jeremy,
>> 
>> knowing pretty little about networking, it nevertheless seems to me
>> that the different placement of skb_checksum_setup() (in the receive
>> paths of pv-ops vs in various transmit paths in legacy) poses a
>> compatibility problem (nothing done on either side if sending from
>> pv-ops to legacy, and done on both ends when sending from legacy
>> to pv-ops). Am I overlooking something here?
> 
> Possibly confusion due to the backwards naming convention in netback?

No - note that I wrote it specifically this way in the original mail.

> The pvops dom0 side calls skb_checksum_setup in net_tx_submit which
> (counter-intuitively) is the function which receives the skb from the
> guest and passes it up to the dom0 network stack (i.e. it handles guest
> tx).
> 
> Since we call skb_checksum_setup on the ingress path all skbs in the
> domain 0 network stack always have their checksum fields correctly
> initialised and there is never anything to be done when transmitting
> transmitting out the other side, either to another domU or to a physical
> device, and therefore it doesn't matter which kernel the domU is
> running.
> 
> On legacy dom0 skb_checksum_setup is called on the generic transmit
> path, so skbs in the domain 0 network stack can have uninitialised
> checksum fields but this is always fixed up before passing back down to
> either netback (called the rx path in netback parlance) or a physical
> device. This can (and has) caused trouble in the past where networking
> subsystems are interested in the checksum fields before egress, e.g. we
> needed to do fixup in various netfilter code paths etc.

Yes, I can see the benefit of doing it the pv-ops way. The question is
what happens for a transmission from pv-ops (frontend or backend -
nothing done in the transmit path) to legacy (again frontend or
backend - nothing done in the receive path). Secondary question was
whether the duplicated effort on transmission the other way around
may be a (performance) issue.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.