Open Stack

Xu Wang <xu at hyper.sh> 于2019年6月12日周三 上午11:00写道：

> I am fine to remove the bridge and I don't think there are cases could
> only work with the bridge.
>
> My colleague Wei has some thoughts on the tc-filter as default, I am
> asking him to post his concern here.
>

hmm... I'm thinking that bridge is more generally available than tcfilter
for the default networking model[1], but as we have change
that default to tcfilter, I'm fine with removing the bridge.

[1]: https://github.com/kata-containers/runtime/issues/1742


>
> On Wed, Jun 12, 2019 at 3:57 AM Ernst, Eric <eric.ernst at intel.com> wrote:
>
>> Hey cloudy-virt-buds –
>>
>>
>>
>> We have a long standing PR from Manohar Castelino in the runtime repo,
>> [1], which removes the bridge networking model.
>>
>>
>>
>> In the bridge networking model, a bridge is created in the network
>> namespace, and the veth is connected to the VM’s tap. This is the least
>> performant and a bit more complex than necessary.  We recommend end-users
>> utilize tc-filter (default) or macvtap.
>>
>>
>>
>> Zhang Wei brought up the concern of whether end-users could be using
>> bridge today.  I hope they aren’t, but am now considering whether this
>> should be a 2.0 candidate, and whether this should be considered a breaking
>> change.
>>
>>
>>
>> Feedback?  I’d like input from other AC members here so we can make
>> forward progress on this PR, and/or on 2.0 planning.
>>
>>
>>
>> Thanks,
>>
>> Eric
>>
>>
>>
>> [1] - https://github.com/kata-containers/runtime/pull/1214
>>
>>
>> _______________________________________________
>> kata-dev mailing list
>> kata-dev at lists.katacontainers.io
>> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>>
>
>
> --
> Xu Wang
> Senior Staff Engineer at AntFin
> A member of Kata Containers project
> github/twitter/wechat: @gnawux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190612/96cd3c20/attachment-0001.html>