Re: [ovs-discuss] (no subject)
Hi, Working on: RYU version:3.27 Ovs version: 27.2 OpenFlow version:1.5. I need to get the following stats for each port: (PORT_NUMBER,IN_UNICAST,OUT_UNICAST,IN_MULTICAST,OUT_MULTICAST,IN_BROADCAST,OUT_BROADCAST ) I tried getting the statistics by adding 3 flows for each port which matches the unicast, broadcast, and multicast packets and retrieved the statistics of each flow using the OFPFlowStatsRequest API from the RYU. And i was able to get the following stats for each flow (byte_count,cookie,duration_nsec,duration_sec,flags,hard_timeout,idle_timeout,in_port ,packet_count,table_id) So i was able to get the IN_UNICAST,IN_BROADCAST,IN_MULTICAST for each por, but i dint find any way to get the OUT_UNICAST,OUT_BROADCAST,OUT_MULTICAST. It would be helpful if you suggest me a way to get the following statistics . Thanks in advance. Regards, Shivani Dommeti. On Thu, Dec 7, 2017 at 11:39 AM, shivani dommeti wrote: > Hi all, > > I am using OVS version 2.8.2 > I have a problem when executing "insert-buckets".I created a group of type > select and when i try to insert a bucket using "insert-bucket" command > supported by OpenFlow1.5 the group type gets changed from "select" to "all" > (type=select -> type=all). Can I keep group's properties such as type, > selection_method, fields when inserting new buckets? > > Your help would be appreciated. > > Thanks, > > Shivani. > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow
On Fri, Feb 23, 2018 at 03:51:28PM -0800, Han Zhou wrote: > On Fri, Feb 23, 2018 at 2:17 PM, Ben Pfaff wrote: > > > > On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote: > > > On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff wrote: > > > > > > > > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez > wrote: > > > > > @Han, I can try rebase the patch if you want but that was > > > > > basically renaming the Address_Set table and from Ben's > > > > > comment, it may be better to keep the name. Not sure, > > > > > however, how we can proceed to address Lucas' points in > > > > > this thread. > > > > > > > > I wouldn't rename the table. It sounds like the priority should be to > > > > add support for sets of port names. I thought that there was already > a > > > > patch for that to be rebased, but maybe I misunderstood. > > > > > > I feel it is better to add a new table for port group explicitly, and > the > > > column type can be a set of weak reference to Logical_Switch_Port. > > > The benefits are: > > > - Better data integrity: deleting a lport automatically deletes from the > > > port group > > > - No confusion about the type of records in a single table > > > - Existing Address_Set mechanism will continue to be supported without > any > > > change > > > - Furthermore, the race condition issue brought up by Lucas can be > solved > > > by supporting port-group in IP address match condition in > ovn-controller, > > > so that all addresses in the lports are used just like how AddressSet is > > > used today. And there is no need for Neutron networking-ovn to use > > > AddressSet any more. Since addresses are deduced from lports, the > ordering > > > of deleting/adding doesn't matter any more. > > > > > > How does this sound? > > > > Will we want sets of Logical_Router_Ports later? > At least I don't see any use case in Neutron for router ports since > Security Group is only for VIF ports. > > There is another tricky point I see while working on implementation. In > Neutron, SG can be applied to ports across different networks, but in OVN > lports works only on its own datapath, so in ovn-controller we need to be > able to pickup related ports from the port-group when translating lflows > for each datapath. I hope this is not an issue. Otherwise, Neutron plugin > will have to divide the group of ports into sub-groups according to the > lswitch they belong to, which would be a pain. I think that we can make ovn-controller gracefully tolerate that. Let's try this implementation. I'm not excited about having a new table for this purpose, but it sounds like the advantages may be worthwhile. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Is a new field in flow.h necessary for matching on a custom v6 extension header?
Makes total sense. I started with PISCES and made some progress, however it feels like going into uncharted waters. I feared I might hit something above my pay grade, so I am back to modifying ovs instead. Best of luck on your P4 journey :) 2018-02-23 19:22 GMT+01:00 Ben Pfaff : > Ultimately, I expect a P4-based solution, in which the controller > supplies a P4 program that extracts the fields that it is interested in. > This is my big project for OVS 2.10. (I don't know how successful I'll > be yet.) > > On Fri, Feb 23, 2018 at 12:37:40AM +0100, Alan Kayahan wrote: > > I understand that there must be a construct in the struct flow, and > > introducing a new be32 will save the day for me. However looking at this > > from a broader perspective, say matching on the fields of any v6 > extension > > header made into the OF specification, neither adding individual fields > nor > > adding every v6 extension header into the struct flow looks elegant to > me. > > What do you think? > > > > 2018-02-21 17:10 GMT+01:00 Ben Pfaff : > > > > > On Mon, Feb 19, 2018 at 06:15:30PM +0100, Alan Kayahan wrote: > > > > I have a custom v6 extension header, in which I would like to > perform an > > > > LPM match on only one 32bit field. > > > > > > > > Since an extension header is technically not a new field, do I still > need > > > > to introduce anything in the struct flow? > > > > > > Without anything in struct flow, how do you propose to match on it? > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
