All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@redhat.com>
To: Jesse Gross <jesse@nicira.com>
Cc: Ben Pfaff <blp@nicira.com>,
	"dev@openvswitch.org" <dev@openvswitch.org>,
	Ben Hutchings <bhutchings@solarflare.com>,
	fleitner@redhat.com, dborkmann@redhat.com,
	netdev <netdev@vger.kernel.org>
Subject: Re: [ovs-dev] [PATCH] linux: Signal datapath that unaligned Netlink message can be received
Date: Wed, 13 Nov 2013 10:46:53 +0100	[thread overview]
Message-ID: <52834A8D.9040009@redhat.com> (raw)
In-Reply-To: <CAEP_g=_KWgmfVkNLPGYr=WjNR=UKSt3PhkqU8PE6Ug3ju2R3ig@mail.gmail.com>

On 11/13/2013 07:11 AM, Jesse Gross wrote:
> On Mon, Nov 11, 2013 at 11:53 PM, Thomas Graf <tgraf@redhat.com> wrote:
>> On 11/11/2013 04:50 PM, Ben Pfaff wrote:
>>>
>>> On Mon, Nov 11, 2013 at 04:36:24PM +0100, Thomas Graf wrote:
>>>>
>>>> Following commit (''netlink: Do not enforce alignment of last Netlink
>>>> attribute''), signal the ability to receive unaligned Netlink messages
>>>> to the datapath to enable utilization of zerocopy optimizations.
>>>>
>>>> Signed-off-by: Thomas Graf <tgraf@redhat.com>
>>>
>>>
>>> Seems OK from a userspace point of view.  I am a little concerned that
>>> downgrading userspace without deleting and re-creating the datapath
>>> (e.g. via "force-reload-kmod") will result in a totally broken setup
>>> since userspace will then drop every packet from the kernel.
>>
>>
>> Is that something that occurs occasionally in installations? Utilizing
>> the version field in the genl header could be used to track this and
>> clear user_features.
>
> It's probably a good idea. I could see us having more of these
> features flags in the future (although obviously we should try to
> avoid them if possible) and, as Ben said, it would potentially lead to
> a bad state otherwise.
>
> I'm not sure exactly what you have in mind though, can you elaborate a little?

My initial thought was to use a version field to notice the replacement
of user space. On second thought that is not required, modifying user
space to provide the user features in OVS_DP_CMD_GET as well will
overwrite the features. Resetting user_features to 0 if not features are
provided will provide backwards compatibility to versions not aware of
user features yet. Thoughts?

> (By the way, it might be a good idea to keep the same CC list on all
> of the patches. Otherwise, some people might miss parts of the
> discussion.)

I did not CC netdev because this is a pure user space patch and the
respective kernel bits are included in v5 of the kernel series.

  reply	other threads:[~2013-11-13  9:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51e10053434e3afdf9940d9be7d9f0ff4788d1f7.1384184155.git.tgraf@redhat.com>
     [not found] ` <20131111155014.GC32602@nicira.com>
     [not found]   ` <5280FD6D.9000609@redhat.com>
     [not found]     ` <5280FD6D.9000609-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-13  6:11       ` [PATCH] linux: Signal datapath that unaligned Netlink message can be received Jesse Gross
2013-11-13  9:46         ` Thomas Graf [this message]
2013-11-15  9:32           ` [ovs-dev] " Jesse Gross
2013-11-15  9:47             ` Thomas Graf
2013-11-15 10:29               ` Jesse Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52834A8D.9040009@redhat.com \
    --to=tgraf@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=blp@nicira.com \
    --cc=dborkmann@redhat.com \
    --cc=dev@openvswitch.org \
    --cc=fleitner@redhat.com \
    --cc=jesse@nicira.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.