[ovs-dev] [PATCH] netdev-linux: fix bug of ovs ingress policing with linux tc

Ben Pfaff blp at nicira.com
Mon Aug 24 18:25:38 UTC 2015


I'm only interested in a general solution, as described in the cited
email.  I'm not going to take this change.

On Thu, Aug 20, 2015 at 03:04:52PM +0800, ychen wrote:
> yes, maybe it is not a perfect resolution, but it did resolved 
> this problem: when tapB deleted from ovs bridge, tapA's ingress rule disappeared
> and of course, there maybe some problem I haven't consider, 
> so I want more detailed suggestions, thanks!
> 
> 
> 
> 
> 
> 
> At 2015-08-20 13:03:53, "Ben Pfaff" <blp at nicira.com> wrote:
> >On Thu, Aug 20, 2015 at 11:29:07AM +0800, ychen wrote:
> >> port's ingress qdisc rule will automatically disappeared after
> >> the following steps:
> >> 1)use ip tuntap to create port tapA and tapB
> >> 2)set tapA and tapB to ingress qdisc with linux tc command
> >> 3)add tapA to ovs bridge
> >> 4)add tapB to the same ovs bridge(ingress rule disappear for tapA)
> >> ingress_policing_rate equals to 0 means disable ingress policing,
> >> so set flag VALID_POLICING only when this paramter is effective,
> >> and before send deleteing ingress qdisc message to kernel, first check
> >> whether need to do this action. if settings not changed or policing is not
> >> enabled with ingress_policing_rate equal to 0, do not send any message.
> >> when interface's MAC,MTU,link state changed, there will be a RTM_NETLINK 
> >> message from kernel, and keep the flag VALID_POLICING as it is.
> >
> >I'm still not going to take this.  As I said before, I don't see how
> >this solves the problem described in
> >http://openvswitch.org/pipermail/discuss/2015-May/017687.html.  I don't
> >see much value in just tweaking the parameters of the problem.



More information about the dev mailing list