[ovs-dev] [PATCH 2/2 net-next] openvswitch: Use skb_zerocopy() for upcall

Jesse Gross jesse at nicira.com
Mon Nov 11 01:55:15 UTC 2013


On Mon, Nov 11, 2013 at 7:40 AM, Thomas Graf <tgraf at suug.ch> wrote:
> On 11/09/13 at 10:02pm, Ben Hutchings wrote:
>> On Fri, 2013-11-08 at 10:15 +0100, Thomas Graf wrote:
>> > Use of skb_zerocopy() avoids the expensive call to memcpy() when
>> > copying the packet data into the Netlink skb. Completes checksum
>> > through skb_checksum_help() if needed.
>> >
>> > Netlink messaged must be properly padded and aligned to meet
>> > sanity checks of the user space counterpart.
>> >
>> > Cost of memcpy is significantly reduced from:
>> > +   7.48%       vhost-8471  [k] memcpy
>> > +   5.57%     ovs-vswitchd  [k] memcpy
>> > +   2.81%       vhost-8471  [k] csum_partial_copy_generic
>> >
>> > to:
>> > +   5.72%     ovs-vswitchd  [k] memcpy
>> > +   3.32%       vhost-5153  [k] memcpy
>> > +   0.68%       vhost-5153  [k] skb_zerocopy
>> >
>> > (megaflows disabled)
>> >
>> > Signed-off-by: Thomas Graf <tgraf at suug.ch>
>> > ---
>> >  net/openvswitch/datapath.c | 52 +++++++++++++++++++++++++++++++++++++++-------
>> >  1 file changed, 45 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
>> > index 1408adc..3f170e3 100644
>> > --- a/net/openvswitch/datapath.c
>> > +++ b/net/openvswitch/datapath.c
>> [...]
>> > @@ -441,13 +449,43 @@ static int queue_userspace_packet(struct net *net, int dp_ifindex,
>> >                       nla_len(upcall_info->userdata),
>> >                       nla_data(upcall_info->userdata));
>> >
>> > -   nla = __nla_reserve(user_skb, OVS_PACKET_ATTR_PACKET, skb->len);
>> > +   /* Only reserve room for attribute header, packet data is added
>> > +    * in skb_zerocopy() */
>> > +   if (!(nla = nla_reserve(user_skb, OVS_PACKET_ATTR_PACKET, 0)))
>> > +           goto out;
>> > +   nla->nla_len = nla_attr_size(skb->len);
>> >
>> > -   skb_copy_and_csum_dev(skb, nla_data(nla));
>> > +   skb_zerocopy(user_skb, skb, skb->len, hlen);
>> >
>> > -   genlmsg_end(user_skb, upcall);
>> > -   err = genlmsg_unicast(net, user_skb, upcall_info->portid);
>> > +   /* OVS user space expects the size of the message to be aligned to
>> > +    * NLA_ALIGNTO. Aligning nlmsg_len is not enough, the actual bytes
>> > +    * read must match nlmsg_len.
>> > +    */
>> > +   plen = NLA_ALIGN(user_skb->len) - user_skb->len;
>> > +   if (plen > 0) {
>> > +           int nr_frags = skb_shinfo(user_skb)->nr_frags;
>> > +
>> > +           if (nr_frags) {
>> > +                   skb_frag_t *frag;
>> > +
>> > +                   frag = &skb_shinfo(user_skb)->frags[nr_frags -1];
>> > +                   skb_frag_size_add(frag, plen);
>>
>> It looks like this is effectively padding with whatever happens to
>> follow the original packet content.  This could result in a small
>> information leak.  If the fragment has non-zero offset and already
>> extends to the end of a page, this could result in a segfault as the
>> next page may be unmapped.
>>
>> Perhaps you could add the padding as an extra fragment pointing to a
>> preallocated zero page.  If the skb already has the maximum number of
>> fragments, you would have to copy the last fragment in order to add
>> padding.
>
> You are right and thanks for the review Ben.
>
> Realizing how complex this becomes I'm leaning towards avoiding
> padding alltogether by fixing OVS user space to no longer enforce
> it, signal this capability via a flag to the kernel and only
> perform zerocopy for enabled OVS user space counterparts.

It seems like at a minimum it would be a good idea to start by
patching userspace now. That would at least begin to limit the scope
of the problem.



More information about the dev mailing list