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" <b...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
