All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Zhang, Chen" <chen.zhang@intel.com>,
	qemu-dev <qemu-devel@nongnu.org>,
	Li Zhijian <lizhijian@cn.fujitsu.com>
Subject: Re: [PATCH V4 1/3] net/filter: Remove vnet_hdr from filter-mirror and filter-redirector
Date: Wed, 27 Oct 2021 09:19:07 +0200	[thread overview]
Message-ID: <87ee87aqac.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CACGkMEvQ638LTT-YsLmGNONDCiBJFJ9JOVrDTeH_ktLp6D7gbg@mail.gmail.com> (Jason Wang's message of "Wed, 27 Oct 2021 14:45:28 +0800")

Jason Wang <jasowang@redhat.com> writes:

> On Wed, Oct 27, 2021 at 2:40 PM Zhang, Chen <chen.zhang@intel.com> wrote:

[...]

>> > >> I wonder if we break management layer. If yes, maybe it's better to
>> > >> keep the vnet_hdr_support here.
>> > >
>> > > Yes and no,   With this series of patches, filters have ability to automatically
>> > > Configure the appropriate vnet_hdr_support flag according to the current environment.
>> > > And can report error when can't fixing the vnet_hdr(The user cannot fix it from the previous way ).
>> > > So I think no need for the user to configure this option, some relevant background knowledge required.
>> > >
>> > > For the management layer, keep the vnet_hdr_support may be meaningless except for compatibility.
>> > > In this situation, Do you think we still need to keep the vnet_hdr_support for management layer?
>> >
>> >
>> > So it depends on whether management layer like libvirt has already
>> > supported this. If yes, we may get errors using new qemu with old libvirt?
>>
>> As far as I know, Current management layer like upstream libvirt is no COLO official support yet.
>> And some real CSPs use libvirt passthrough qmp command to Qemu for manage COLO VM.
>
> So the question still, it looks to me it requires the modification of
> the layers on top of libvirt? If the answer is yes, we'd better keep
> that compatibility.

When in doubt, maintain compatibility.

We may want to deprecate parameters that have become unnecessary.

[...]



  parent reply	other threads:[~2021-10-27  7:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 18:17 [PATCH V4 0/3] net/filter: Optimize filters vnet_hdr support Zhang Chen
2021-10-26 18:17 ` [PATCH V4 1/3] net/filter: Remove vnet_hdr from filter-mirror and filter-redirector Zhang Chen
2021-10-27  4:45   ` Jason Wang
2021-10-27  6:19     ` Zhang, Chen
2021-10-27  6:24       ` Jason Wang
2021-10-27  6:40         ` Zhang, Chen
2021-10-27  6:45           ` Jason Wang
2021-10-27  6:50             ` Zhang, Chen
2021-10-27  7:19             ` Markus Armbruster [this message]
2021-10-26 18:17 ` [PATCH V4 2/3] net/filter: Remove vnet_hdr from filter-rewriter Zhang Chen
2021-10-26 18:17 ` [PATCH V4 3/3] net/colo-compare.c: Remove vnet_hdr and check in payload from colo-compare Zhang Chen

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=87ee87aqac.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=chen.zhang@intel.com \
    --cc=jasowang@redhat.com \
    --cc=lizhijian@cn.fujitsu.com \
    --cc=qemu-devel@nongnu.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.