[ovs-dev] [PATCH] netdev-linux: Fix ingress policing burst rate configuration via tc
The tc_police structure was filled with a value calculated in bits instead of bytes while bytes were expected. This led the setting of an x8 higher burst value. Documentation and defaults have been corrected accordingly to minimize nuisances on users sticking to the defaults. The suggested burst value is now 80% of policing rate to make sure TCP works correctly. Signed-off-by: Miguel Angel Ajo Tested-by: Miguel Angel Ajo --- FAQ.md | 2 +- lib/netdev-linux.c | 14 -- vswitchd/vswitch.xml | 4 ++-- 3 files changed, 7 insertions(+), 13 deletions(-) diff --git a/FAQ.md b/FAQ.md index 04ffc84..7dcdb4c 100644 --- a/FAQ.md +++ b/FAQ.md @@ -1124,7 +1124,7 @@ A: A policing policy can be configured on an interface to drop packets generate to 10Mbps: ovs-vsctl set interface vif1.0 ingress_policing_rate=1 - ovs-vsctl set interface vif1.0 ingress_policing_burst=1000 + ovs-vsctl set interface vif1.0 ingress_policing_burst=8000 Traffic policing can interact poorly with some network protocols and can have surprising results. The "Ingress Policing" section of diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c index a7d7ac7..a2b6b8a 100644 --- a/lib/netdev-linux.c +++ b/lib/netdev-linux.c @@ -2045,7 +2045,7 @@ netdev_linux_set_policing(struct netdev *netdev_, int error; kbits_burst = (!kbits_rate ? 0 /* Force to 0 if no rate specified. */ - : !kbits_burst ? 1000 /* Default to 1000 kbits if 0. */ + : !kbits_burst ? 8000 /* Default to 8000 kbits if 0. */ : kbits_burst); /* Stick with user-specified value. */ ovs_mutex_lock(&netdev->mutex); @@ -4720,21 +4720,15 @@ tc_add_policer(struct netdev *netdev, tc_police.mtu = mtu; tc_fill_rate(&tc_police.rate, ((uint64_t) kbits_rate * 1000)/8, mtu); -/* The following appears wrong in two ways: - * - * - tc_bytes_to_ticks() should take "bytes" as quantity for both of its - * arguments (or at least consistently "bytes" as both or "bits" as - * both), but this supplies bytes for the first argument and bits for the - * second. - * - * - In networking a kilobit is usually 1000 bits but this uses 1024 bits. +/* The following appears wrong in one way: In networking a kilobit is + * usually 1000 bits but this uses 1024 bits. * * However if you "fix" those problems then "tc filter show ..." shows * "125000b", meaning 125,000 bits, when OVS configures it for 1000 kbit == * 1,000,000 bits, whereas this actually ends up doing the right thing from * tc's point of view. Whatever. */ tc_police.burst = tc_bytes_to_ticks( -tc_police.rate.rate, MIN(UINT32_MAX / 1024, kbits_burst) * 1024); +tc_police.rate.rate, MIN(UINT32_MAX / 1024, kbits_burst) * 1024 / 8); tcmsg = tc_make_request(netdev, RTM_NEWTFILTER, NLM_F_EXCL | NLM_F_CREATE, &request); diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index 7d6976f..fca238d 100644 --- a/vswitchd/vswitch.xml +++ b/vswitchd/vswitch.xml @@ -2434,7 +2434,7 @@ Maximum burst size for data received on this interface, in kb. The -default burst size if set to 0 is 1000 kb. This value +default burst size if set to 0 is 8000 kbit. This value has no effect if is 0. @@ -2442,7 +2442,7 @@ which is important for protocols like TCP that react severely to dropped packets. The burst size should be at least the size of the interface's MTU. Specifying a value that is numerically at least as - large as 10% of helps TCP come + large as 80% of helps TCP come closer to achieving the full rate. -- 1.8.3.1 Before the patch we have: # ovs-vsctl -- --may-exist add-port br-int test-port -- set Interface # test-port type=internal # ovs-vsctl set interface test-port ingress_policing_rate=1 # ovs-vsctl set interface test-port ingress_policing_burst=1000 # tc filter show dev test-port parent : filter protocol all pref 49 basic filter protocol all pref 49 basic handle 0x1 police 0x1 rate 1Kbit burst 1000Kb mtu 64Kb action drop overhead 0b ref 1 bind 1 After the patch we have: # ovs-vsctl set interface test-port ingress_policing_rate=1 # ovs-vsctl set interface test-port ingress_policing_burst=1000 # tc filter show dev test-port parent : filter protocol all pref 49 basic filter protocol all pref 49 basic handle 0x1 police 0x2 rate 1Kbit burst 125Kb mtu 64Kb action drop overhead 0b ref 1 bind 1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] About debug the vswitchd using gdb -p
Did you recompile/install openvswitch with debug info and provided the path to the executable file via the gdb file command as gdb is suggesting? The breakpoint is pending because gdb cannot map the function name to the code address space until it's able to read the debug info for vswitchd. openvswitcher wrote: Hi, all I want to ask about how to make the vswitchd break on the breakpoint by gdb. I attached the vswitchd process using 'gdb -p' as bellow: gdb --pid=31212 (gdb) b dpif_linux.c:dpif_linux_port_add No symbol table is loaded. Use the "file" command. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (dpif_linux:dpif_linux_port_add) pending. (gdb) c Continuing. But when I used "ovs-vsctl add-port br0 eth1" command, the process had not been broken on the breakpoint. Could you tell me how make it OK? Thanks. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] Include vtep dir into the sandbox path
Otherwise the built vtep-ctl is not available from the sandbox command line. --- tutorial/ovs-sandbox | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tutorial/ovs-sandbox b/tutorial/ovs-sandbox index c8fc32f..5e0553b 100755 --- a/tutorial/ovs-sandbox +++ b/tutorial/ovs-sandbox @@ -258,7 +258,7 @@ if $built; then echo >&2 'build not found, please change set $builddir or change directory' exit 1 fi -PATH=$builddir/ovsdb:$builddir/vswitchd:$builddir/utilities:$PATH + PATH=$builddir/ovsdb:$builddir/vswitchd:$builddir/utilities:$builddir/vtep:$PATH if $ovn; then PATH=$builddir/ovn:$builddir/ovn/controller:$builddir/ovn/controller-vtep:$builddir/ovn/northd:$builddir/ovn/utilities:$PATH fi -- 1.8.3.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] Include vtep dir into the sandbox path
Sorry for the duplicate, I got a rejection on first one from the server, but somehow is on the mail list archive now that I look. and I guess I'm missing a Signed-off-my: Miguel Angel Ajo right? majop...@redhat.com wrote: From: Miguel Angel Ajo Otherwise the built vtep-ctl is not available from the sandbox command line. --- tutorial/ovs-sandbox | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tutorial/ovs-sandbox b/tutorial/ovs-sandbox index c8fc32f..5e0553b 100755 --- a/tutorial/ovs-sandbox +++ b/tutorial/ovs-sandbox @@ -258,7 +258,7 @@ if $built; then echo>&2 'build not found, please change set $builddir or change directory' exit 1 fi -PATH=$builddir/ovsdb:$builddir/vswitchd:$builddir/utilities:$PATH + PATH=$builddir/ovsdb:$builddir/vswitchd:$builddir/utilities:$builddir/vtep:$PATH if $ovn; then PATH=$builddir/ovn:$builddir/ovn/controller:$builddir/ovn/controller-vtep:$builddir/ovn/northd:$builddir/ovn/utilities:$PATH fi ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/3] QOS support in OVN
Hi!, Russell Bryant wrote: On 01/13/2016 11:30 AM, Russell Bryant wrote: On 01/11/2016 08:19 PM, Ben Pfaff wrote: On Tue, Jan 05, 2016 at 07:33:16PM +0530, bscha...@redhat.com wrote: This patch series enables QOS support in OVN. Only two parameters (policing_rate and policing_burst) are enabled through this patch series. Babu Shanmugam (3): ovn: ovn-controller changes for qos settings ovn: Qos options for VMI updated in ovn-sb.xml ovn: Qos options for VMI updated in ovn-nb.xml We found previously that ingress policing works particularly badly. It isn't accurate and some kind of traffic get handled in a really bad way. Have you have a different experience? I suggested the QoS work item. The background is just that I'm looking to get parity with what OpenStack Neutron exposes for the current integration. Hopefully the limitations are adequately reflected in docs. Would you be OK including this support with appropriate caveats in the docs? I also asked the dev of the existing Neutron integration to weigh in about their implementation and experience. We're using ingress policing in neutron as a simple way to provide VM/container - egress bandwidth policing. It works well with TCP, but of course, UDP and other types of traffic may need some sort of queuing, we didn't uses queues, because neutron reference implementation makes a heavy use of NORMAL rules and port tagging to direct traffic to the right place, that makes it impossible to use queues. Also, I found that to use queues (for VM-egress traffic) we need to have one queue per traffic flow/port in the outgoing port, and as I understood it, we can only create queues for linux kernel visible ports (that excludes patch ports, tunnel ports and OVS internal port bonds, but includes veth based patch ports, and physical interfaces). Please correct me if I'm wrong here, probably there is some sort of alternative here equivalent to IMQ's, I'm sadly not an expert in this area. So, even if it was a little bit limited seemed like reasonable initial step to provide VM-egress bandwidth limits. (we left the limitations documented: Application or protocol needs to expect packet drops). VM-ingress/switch-egress are very easily implemented with queues. Best regards, Miguel Ángel. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] ovn-controller: Verify bridge ports before changing.
Good catch :) Ben Pfaff wrote: OVSDB is transactional but it does not have built-in protection from dirty reads. To avoid those, it's necessary to manually add verification to transactions to ensure that any data reads whose values were essential to later writes have not changed. ovn-controller didn't do that for the "ports" column in the Bridge table, which means that if the set of ports changed when it didn't expect it, it could revert changes made by other database clients. In particular this showed up in a scale test, where ovn-controller would delete "vif" ports added via ovs-vsctl. (It's easy to see exactly what happened by looking in the database log with "ovsdb-tool -mm show-log".) Reported-by: Russell Bryant Reported-at: http://openvswitch.org/pipermail/dev/2015-June/056326.html Signed-off-by: Ben Pfaff --- ovn/controller/chassis.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ovn/controller/chassis.c b/ovn/controller/chassis.c index 63e1160..cf18dd0 100644 --- a/ovn/controller/chassis.c +++ b/ovn/controller/chassis.c @@ -262,6 +262,7 @@ tunnel_add(struct tunnel_ctx *tc, const char *new_chassis_id, ports[i] = tc->br_int->ports[i]; } ports[tc->br_int->n_ports] = port; + ovsrec_bridge_verify_ports(tc->br_int); ovsrec_bridge_set_ports(tc->br_int, ports, tc->br_int->n_ports + 1); sset_add(&tc->port_names, port_name); @@ -282,6 +283,7 @@ bridge_delete_port(const struct ovsrec_bridge *br, ports[n++] = br->ports[i]; } } + ovsrec_bridge_verify_ports(br); ovsrec_bridge_set_ports(br, ports, n); free(ports); } @@ -430,6 +432,7 @@ chassis_destroy(struct controller_ctx *ctx) ports[n++] = ctx->br_int->ports[i]; } } + ovsrec_bridge_verify_ports(ctx->br_int); ovsrec_bridge_set_ports(ctx->br_int, ports, n); free(ports); ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Does ovs-2.4 supports egress traffic shaping ?
Egress from the VM/port point of view, or from the switch point of view?. Btw, Justin, I follow up with the question :) , is it possible to use the qos table to do "egress" from the VM/port point of view?, I only managed to do that with the ingress policing [1], is there any way to use queues for switch ingress (port egress), may be combining openflow + enqueue action? Cheers, Miguel Ángel. [1] http://openvswitch.org/support/config-cookbooks/qos-rate-limiting/ Justin Pettit wrote: On Sep 13, 2015, at 10:40 PM, wrote: Hello Team, Does ovs supports traffic shaping . I don't see any configuration related to shaping. Please, let me Know if there exists some configuration to enable traffic shaping. Yes. Look at the "qos" table in the ovs-vswitchd.conf.db man page. There's an example of configuring it in the ovs-vsctl man page. --Justin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] Does ovs-2.4 supports egress traffic shaping ?
Justin Pettit wrote: On Sep 14, 2015, at 12:57 AM, Miguel Angel Ajo wrote: Egress from the VM/port point of view, or from the switch point of view?. I work on the switch, so it's always from its point of view. :-) I was more used to the other point of view :), which brings me a lot of confusion when I talk to bridge guys ;D On the original question, there's a big FAQ entry about configuring QoS in the FAQ: https://github.com/openvswitch/ovs/blob/master/FAQ.md Btw, Justin, I follow up with the question :) , is it possible to use the qos table to do "egress" from the VM/port point of view?, I only managed to do that with the ingress policing [1], is there any way to use queues for switch ingress (port egress), may be combining openflow + enqueue action? Unless it's changed recently, there's not really a good way to do ingress shaping in Linux. You can use the IFB device to allow shaping of ingress traffic in Linux, but I think it has negative performance implications and some other limitations. I'm not aware of anyone using IFB with OVS, though. I'm just remembering a conversation I had with Thomas a few months ago, and then it made sense, but my inverted point of view made me think something had changed because I was able to do VM-ingress shaping. Of course, it was bridge egress what I was doing, and that's why it worked. I also remember a possible workaround plugin a veth to ovs, the other end to a namespace, and using routing to reflect any incoming packet, so you gain a point of control over the egress path of the packets. I noticed that ingress_policing_rate / _burst parameters on VM tap ports didn't drop any packets opposed to what documentation says. I may need to re-check that, but I didn't see any packet drop counters raising, could it be because as being on the same host, the sender get's blocked?, or that's not possible and I didn't look at the right counters... I understand that, from a remote host, once the packet was received you either throw it, queue it, or use it.., but locally, if the linux stack is smart enough (it could block the in-host sender). I'm looking at all this because we're interested in adding support for traffic classification in neutron qos, so we can apply certain ingress/egress shaping (or dscp/../etc marking) based on packet matching. --Justin ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] python: Update Python version checks.
On Thu, Apr 14, 2016 at 11:09 PM, Ben Pfaff wrote: > On Thu, Apr 14, 2016 at 05:00:48PM -0400, Russell Bryant wrote: >> Instead of checking the raw version, use the six.PY2 and six.PY3 helpers >> to determine if Python 2 or Python 3 are in use. >> >> In one case, the check was to determine if the Python version was >= >> 2.6. We now only support >= 2.7, so this check would always be true. >> >> Signed-off-by: Russell Bryant > > Acked-by: Ben Pfaff Acked-by: Miguel Angel Ajo ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v1 2/2] netdev-dpdk.c: Add ingress-policing functionality.
On Wed, Apr 13, 2016 at 4:48 PM, Ian Stokes wrote:
> This patch provides the modifications required in netdev-dpdk.c and
> vswitch.xml to enable ingress policing for DPDK interfaces.
>
> This patch implements the necessary netdev functions to netdev-dpdk.c as
> well as various helper functions required for ingress policing.
>
> The vswitch.xml has been modified to explain the expected parameters and
> behaviour when using ingress policing.
>
> The INSTALL.DPDK.md guide has been modified to provide an example
> configuration of ingress policing.
>
> Signed-off-by: Ian Stokes
> ---
>
> v1:
>
> *INSTALL.DPDK.md
> - Add ingress_policing usage example.
>
> *NEWS
> - Add support for ingress_policing to DPDK section.
>
> *netdev-dpdk.c
> - Add ingress_policer struct.
> - Modify struct netdev-dpdk to include a ovsrcu pointer to an ingress
> policer.
> - Modify netdev_dpdk_init() to initialise ingress policer to null.
> - Add function 'ingress_policer_run()'to process packets with a given
> netdev, rte_mbuf and packet count.
> - Modified 'netdev_dpdk_vhost_update_rx_counters()' to accept new
> parameter int dropped representing number of packets dropped.
> - Modified 'netdev_dpdk_vhost_update_rx_counters()' to update number of
> dropped packets in stats->rx_dropped.
> - Modified 'netdev_dpdk_vhost_rxq_recv()' to check and call
> ingress_policing functionality with 'ingress_policer_run()'.
> - Modified 'netdev_dpdk_rxq_recv()' to check and call
> ingress_policing functionality with 'ingress_policer_run()'.
> - Modified 'netdev_dpdk_rxq_recv()' to update rx dropped stats.
> - Modified 'netdev_dpdk_vhost_get_stats()' to add support for rx_dropped.
> - Add function 'netdev_dpdk_policer_construct__()' to create an
> ingress_policer.
> - Add function 'netdev_dpdk_policer_destruct__()' to destroy an ingress
> policer.
> - Add function 'netdev_dpdk_set_policing()' responsible for calling
> helper functions to create and destroy an ingress policer for the
> device.
> - Add function 'netdev_dpdk_get_ingress_policer()' to return a pointer
> to the ingress_policer using the ovsrcu_get function.
>
> *vswitch.xml
> - Modify ingress policing section to include support in OVS with DPDK.
> ---
> INSTALL.DPDK.md | 19 ++
> NEWS |1 +
> lib/netdev-dpdk.c| 173
> --
> vswitchd/vswitch.xml |4 +-
> 4 files changed, 190 insertions(+), 7 deletions(-)
>
> diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
> index 9ec8bf6..df2c6cd 100644
> --- a/INSTALL.DPDK.md
> +++ b/INSTALL.DPDK.md
> @@ -227,6 +227,25 @@ Using the DPDK with ovs-vswitchd:
> For more details regarding egress-policer parameters please refer to the
> vswitch.xml.
>
> +9. Ingress Policing Example
> +
> + Assuming you have a vhost-user port receiving traffic consisting of
> + packets of size 64 bytes, the following command would limit the reception
> + rate of the port to ~1,000,000 packets per second:
> +
> + `ovs-vsctl set interface vhost-user0 ingress_policing_rate=368000
> +ingress_policing_burst=1000`
> +
> + To examine the ingress policer configuration of the port:
> +
> + `ovs-vsctl list interface vhost-user0`
> +
> + To clear the ingress policer configuration from the port use the
> following:
> +
> + `ovs-vsctl set interface vhost-user0 ingress_policing_rate=0`
> +
> + For more details regarding ingress-policer see the vswitch.xml.
> +
> Performance Tuning:
> ---
>
> diff --git a/NEWS b/NEWS
> index ea7f3a1..d0283fa 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -26,6 +26,7 @@ Post-v2.5.0
> assignment.
> * Type of log messages from PMD threads changed from INFO to DBG.
> * QoS functionality with sample egress-policer implementation.
> + * Add ingress policing functionality.
> - ovs-benchmark: This utility has been removed due to lack of use and
> bitrot.
> - ovs-appctl:
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index fe9c9cb..2d955d3 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -297,6 +297,12 @@ struct dpdk_ring {
> struct ovs_list list_node OVS_GUARDED_BY(dpdk_mutex);
> };
>
> +struct ingress_policer {
> +struct rte_meter_srtcm_params app_srtcm_params;
> +struct rte_meter_srtcm in_policer;
> +rte_spinlock_t policer_lock;
> +};
> +
> struct netdev_dpdk {
> struct netdev up;
> int port_id;
> @@ -342,6 +348,10 @@ struct netdev_dpdk {
> struct qos_conf *qos_conf;
> rte_spinlock_t qos_lock;
>
> +/* Ingress Policer */
> +OVSRCU_TYPE(struct ingress_policer *) ingress_policer;
> +uint32_t policer_rate;
> +uint32_t policer_burst;
> };
>
> struct netdev_rxq_dpdk {
> @@ -355,6 +365,9 @@ static int netdev_dpdk_construct(struct netdev *);
>
> struct virtio_net * netdev_dpdk_get_virtio(const struct netdev_dpdk *dev);
>
> +struct ingress_policer *
> +netdev_dpdk_get_ingress_policer(const struct netdev_dpdk *
Re: [ovs-dev] [PATCH 0/2] ovn: QOS updates with DSCP support
Hi, Ben, Babu, what you're proposing here makes sense, it's aligned with the plans we were shaping for min-bandwidth guarantees in the openvswitch-agent [1] [2] I wasn't aware of the possibility of setting a queue on the external interface, and reference that from set_queue (I need to understand how would the external interface queue can be registered into openvswitch openflow queues -is that currently possible?-) My plan was (in the case of the ovs-agent solution) to add those queues in the "patch" ports connecting br-int to other bridges by turning them into veths when necessary -slow- [br-tun] <---> [br-int] [br-ex*] <---> [br-int] Please note that we plan to tackle [3] (ingress bw limit) by popular request, by attaching a queue to the instance port (for now). In the future, we could also provide min-bw for ingress in the case of having an intermediate veth or device where to attach the queue and count all the passing traffic (to make min effective), but I'd be very happy to stay away from veths because of the performance penalty they introduce. [1] https://bugs.launchpad.net/neutron/+bug/1560963 (min bw) [2] https://bugs.launchpad.net/neutron/+bug/1578989 (min bw scheduling-aware) [3] https://bugs.launchpad.net/neutron/+bug/1560961 (instance ingress max bw limit) On Tue, May 17, 2016 at 1:08 PM, Babu Shanmugam wrote: > Thank you for your answers Ben. > I tried configuring a htb qdisc on a physical interface which is not > attached to any bridge and found the egress shaping working on a tap device > attached to br-int. > > Babu > > > On Tuesday 17 May 2016 01:37 AM, Ben Pfaff wrote: > >> Hi Bryan, I think that you understand how QoS works in NVP. We're >> currently talking about how to implement QoS in OVN. Can you help us >> understand the issues? >> >> ...now back to the conversation already in progress: >> >> On Tue, May 10, 2016 at 05:04:06PM +0530, Babu Shanmugam wrote: >> >>> On Friday 06 May 2016 10:33 PM, Ben Pfaff wrote: >>> But I'm still having trouble understanding the whole design here. Without this patch, OVN applies ingress policing to packets received >>> >from (typically) a VM. This limits the rate at which the VM can >>> introduce packets into the network, and thus acts as a direct (if primitive) way to limit the VM's bandwidth resource usage on the machine's physical interface. With this patch, OVN applies shaping to packets *sent* to (typically) a VM. This limits the rate at which the VM can consume packets*from* the network. This has no direct effect on the VM's consumption of bandwidth resources on the network, because the packets that are discarded have already consumed RX resources on the machine's physical interface and there is in fact no direct way to prevent remote machines from sending packets for the local machine to receive. It might have an indirect effect on the VM's bandwidth consumption, since remote senders using (e.g.) TCP will notice that their packets were dropped and reduce their sending rate, but it's far less efficient at it than shaping packets going out to the network. The design I expected to see in OVN, eventually, was this: - Each VM/VIF gets assigned a queue. Packets received from the VM are tagged with the queue using an OpenFlow "set_queue" action (dunno if we have this as an OVN logical action yet but it's easily added). - OVN programs the machine's physical interface with a linux-htb or linux-hfsc qdisc that grants some min-rate to each queue. >>> From what I understand, to setup egress shaping for a VIF interface >>> - We need a physical interface attached to br-int >>> >> It doesn't have to be attached to br-int, because queuing information is >> preserved over a hop from bridge to bridge and through encapsulation in >> tunnels, but OVN would have to configure queues on the interface >> regardless of what bridge it was in. >> >> - QOS and Queue tables has to be setup for the port entry that corresponds >>> to the physical interface >>> - Packets received from VIF are put in these queues using set_queue. >>> Is my understanding correct? >>> >> Yes, I believe so. >> >> Is there any way that HTB/HFSC queues can work without a physical >>> interface >>> attached to br-int? if not are we going to mandate in some way that a >>> physical interface has to be attached to br-int? >>> >> I don't think it's desirable or necessary to attach the physical >> interface to br-int, only to ensure that the queues are configured on >> it. >> >> Bryan, what does NVP do? In particular, does it configure queues on a >> physical interface without caring what bridge it is attached to? >> >> Thanks, >> >> Ben. >> > > ___ > dev mailing list > dev@openvswitch.org > http:
Re: [ovs-dev] unit of burst in ingress_policing
Hi Ben, I think slawe is not worried about the 1000 vs 1024 difference. But on the fact that when setting 1000kbit burst on an policy, when you check via tc cmdline, you see 1000kbyte. Is TC command line reporting it wrong?, is it TC API?, or is it a bug in OVS?. I'm reading the TC API and cmdline tool trying to identify that, but I probably don't have the expertise... we will see.. Best regards, On Sun, Apr 10, 2016 at 10:25 PM, Ben Pfaff wrote: > No, I'm talking about the rest of the comment, please read it again. > The difference between 1000 vs 1024 bits is a trivial 2.4% difference. > > On Sun, Apr 10, 2016 at 09:46:28PM +0200, Sławek Kapłoński wrote: >> Hello, >> >> Thx for anwear and checking that. AFAIU You are talking about issue with SI >> and IEC units and problem with it. >> I'm not talking about such issue or not issue. What I pointed here is that >> (from comment in ovs code) ovs is doing something like: >> "sbin/tc filter add dev parent : protocol all prio 49 basic >> police rate kbit burst k >> " >> please note this k >> but problem is that when You give "k" to tc it is not kilobits but kiloBYTES. >> So ovs should do something like " burst kbit" in this >> command. Or maybe it is intentional to use "k" there so IMHO message in >> comment should be something like "... burst k" >> >> -- >> Pozdrawiam / Best regards >> Sławek Kapłoński >> sla...@kaplonski.pl >> >> Dnia niedziela, 10 kwietnia 2016 12:36:46 CEST Ben Pfaff pisze: >> > On Thu, Apr 07, 2016 at 09:28:50PM +0200, Sławek Kapłoński wrote: >> > > Hello, >> > > >> > > I'm playing littlebit with ingress policing in openvswitch and I found >> > > some >> > > kind of inconsistency. >> > > In docs and in source code >> > > (https://github.com/openvswitch/ovs/blob/master/ >> > > lib/netdev-linux.c#L4698) there is info that burst is set in kilobits, >> > > but >> > > I found that in fact it is set in kilobytes in tc. >> > > So long story short: >> > > >> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl show >> > > f0d1f90d-174f-47bf-89bc-bf37f2da0271 >> > > >> > > Bridge "br1" >> > > >> > > Port vethA >> > > >> > > Interface vethA >> > > >> > > Port "br1" >> > > >> > > Interface "br1" >> > > >> > > type: internal >> > > >> > > ovs_version: "2.5.0" >> > > >> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl set Interface vethA >> > > ingress_policing_rate=1000 -- set Interface vethA >> > > ingress_policing_burst=100 >> > > >> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl list interface vethA | grep >> > > ingress >> > > ingress_policing_burst: 100 >> > > ingress_policing_rate: 1000 >> > > >> > > >> > > results in: >> > > root@ubuntu-1604-test:/home/ubuntu# tc filter show dev vethA parent : >> > > filter protocol all pref 49 basic >> > > filter protocol all pref 49 basic handle 0x1 >> > > >> > > police 0x1 rate 1Mbit burst 100Kb mtu 64Kb action drop overhead 0b >> > > >> > > ref 1 bind 1 >> > > >> > > >> > > As You can see above, burst is given in "Kb" units what, according to tc >> > > man (http://lartc.org/manpages/tc.txt) means kilobytes. >> > > >> > > So question: is it intentional inconsistency or bug? If bug then where: >> > > in >> > > code or in docs? >> > >> > We applied a fix to the policing code last year, in the following >> > commit. If you read the long comment that it adds, and then compare >> > that with what you're saying, it sounds like tc once had a bug where it >> > confused bits and bytes, and we modified OVS so that it had the same >> > bug. Presumably, now tc's bug has been fixed, and so we should fix OVS >> > the same way. >> > >> > --8<--cut here-->8-- >> > >> > From: Ben Pfaff >> > Date: Fri, 13 Mar 2015 11:30:18 -0700 >> > Subject: [PATCH] netdev-linux: Be more careful about integer overflow in >> > policing. >> > >> > Otherwise the policing limits could make no sense if large rates were >> > specified. >> > >> > Reported-by: Zhangguanghui >> > Signed-off-by: Ben Pfaff >> > Acked-by: Ansis Atteka >> > --- >> > AUTHORS| 1 + >> > lib/netdev-linux.c | 29 ++--- >> > vswitchd/bridge.c | 4 ++-- >> > 3 files changed, 25 insertions(+), 9 deletions(-) >> > >> > diff --git a/AUTHORS b/AUTHORS >> > index fe79acd..d7925db 100644 >> > --- a/AUTHORS >> > +++ b/AUTHORS >> > @@ -345,6 +345,7 @@ Voravit T. vora...@kth.se >> > Yeming Zhao zhaoyem...@gmail.com >> > Ying Chen yingc...@vmware.com >> > Yongqiang Liu liuyq7...@gmail.com >> > +Zhangguanghui zhang.guang...@h3c.com >> > Ziyou Wang ziy...@vmware.com >> > Zoltán Balogh zoltan.bal...@ericsson.com >> > ankur dwivedi ankurengg2...@gmail.com >> > diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c >> > index 662ccc9..6e574cd 100644 >> > --- a/lib/netdev-linux.c >> > +++ b/lib/netdev-l
Re: [ovs-dev] unit of burst in ingress_policing
After looking at iproute2/tc sources and ovs sources, I believe the error is in ovs, In tc, the burst is calculated with tc_calc_xmittime(size, rate) = tick_in_us * TIME_UNITS_PER_SEC * (size/rate) tick_in_us seems to be the number of ticks in a microsecond, and TIME_UNITS_PER_SEC is 100 In ovs the burst is calculated with tc_bytes_to_ticks(rate, size) = ticks_per_s * (size/rate) and we pass "size" as bits, while it should be bytes. https://github.com/openvswitch/ovs/blob/master/lib/netdev-linux.c#L4736 it should be (kbits_burst * 1024) / 8 instead of kbits_burst*1024 If somebody could doublecheck, that'd be great. On Tue, Apr 12, 2016 at 11:05 AM, Miguel Angel Ajo Pelayo wrote: > Hi Ben, > >I think slawe is not worried about the 1000 vs 1024 difference. > >But on the fact that when setting 1000kbit burst on an policy, >when you check via tc cmdline, you see 1000kbyte. > >Is TC command line reporting it wrong?, is it TC API?, or is it a > bug in OVS?. > >I'm reading the TC API and cmdline tool trying to identify that, > but I probably don't have the expertise... we will see.. > > Best regards, > > On Sun, Apr 10, 2016 at 10:25 PM, Ben Pfaff wrote: >> No, I'm talking about the rest of the comment, please read it again. >> The difference between 1000 vs 1024 bits is a trivial 2.4% difference. >> >> On Sun, Apr 10, 2016 at 09:46:28PM +0200, Sławek Kapłoński wrote: >>> Hello, >>> >>> Thx for anwear and checking that. AFAIU You are talking about issue with SI >>> and IEC units and problem with it. >>> I'm not talking about such issue or not issue. What I pointed here is that >>> (from comment in ovs code) ovs is doing something like: >>> "sbin/tc filter add dev parent : protocol all prio 49 basic >>> police rate kbit burst k >>> " >>> please note this k >>> but problem is that when You give "k" to tc it is not kilobits but >>> kiloBYTES. >>> So ovs should do something like " burst kbit" in this >>> command. Or maybe it is intentional to use "k" there so IMHO message in >>> comment should be something like "... burst k" >>> >>> -- >>> Pozdrawiam / Best regards >>> Sławek Kapłoński >>> sla...@kaplonski.pl >>> >>> Dnia niedziela, 10 kwietnia 2016 12:36:46 CEST Ben Pfaff pisze: >>> > On Thu, Apr 07, 2016 at 09:28:50PM +0200, Sławek Kapłoński wrote: >>> > > Hello, >>> > > >>> > > I'm playing littlebit with ingress policing in openvswitch and I found >>> > > some >>> > > kind of inconsistency. >>> > > In docs and in source code >>> > > (https://github.com/openvswitch/ovs/blob/master/ >>> > > lib/netdev-linux.c#L4698) there is info that burst is set in kilobits, >>> > > but >>> > > I found that in fact it is set in kilobytes in tc. >>> > > So long story short: >>> > > >>> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl show >>> > > f0d1f90d-174f-47bf-89bc-bf37f2da0271 >>> > > >>> > > Bridge "br1" >>> > > >>> > > Port vethA >>> > > >>> > > Interface vethA >>> > > >>> > > Port "br1" >>> > > >>> > > Interface "br1" >>> > > >>> > > type: internal >>> > > >>> > > ovs_version: "2.5.0" >>> > > >>> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl set Interface vethA >>> > > ingress_policing_rate=1000 -- set Interface vethA >>> > > ingress_policing_burst=100 >>> > > >>> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl list interface vethA | >>> > > grep >>> > > ingress >>> > > ingress_policing_burst: 100 >>> > > ingress_policing_rate: 1000 >>> > > >>> > > >>> > > results in: >>> > > root@ubuntu-1604-test:/home/ubuntu# tc filter show dev vethA parent >>> > > : >>> > > filter protocol all pref 49 basic >>> > > filter protocol all pref 49 basic handle 0x1 >>> > > >>> > > police 0x1 rate 1Mbit burst 100Kb mtu 64Kb action drop overhead 0b >>> > > >>> > > ref 1
Re: [ovs-dev] unit of burst in ingress_policing
I will send it today. Best, Miguel Angel El 12/4/2016 20:33, "Ben Pfaff" escribió: > Would you like to submit a fix? > > On Tue, Apr 12, 2016 at 01:34:28PM +0200, Miguel Angel Ajo Pelayo wrote: > > After looking at iproute2/tc sources and ovs sources, I believe the > > error is in ovs, > > In tc, the burst is calculated with > > > >tc_calc_xmittime(size, rate) = tick_in_us * TIME_UNITS_PER_SEC * > (size/rate) > > > >tick_in_us seems to be the number of ticks in a microsecond, > >and TIME_UNITS_PER_SEC is 100 > > > > In ovs the burst is calculated with tc_bytes_to_ticks(rate, size) = > > ticks_per_s * (size/rate) > > and we pass "size" as bits, while it should be bytes. > > > > https://github.com/openvswitch/ovs/blob/master/lib/netdev-linux.c#L4736 > > > > it should be (kbits_burst * 1024) / 8 instead of kbits_burst*1024 > > > > If somebody could doublecheck, that'd be great. > > > > > > > > > > On Tue, Apr 12, 2016 at 11:05 AM, Miguel Angel Ajo Pelayo > > wrote: > > > Hi Ben, > > > > > >I think slawe is not worried about the 1000 vs 1024 difference. > > > > > >But on the fact that when setting 1000kbit burst on an policy, > > >when you check via tc cmdline, you see 1000kbyte. > > > > > >Is TC command line reporting it wrong?, is it TC API?, or is it a > > > bug in OVS?. > > > > > >I'm reading the TC API and cmdline tool trying to identify that, > > > but I probably don't have the expertise... we will see.. > > > > > > Best regards, > > > > > > On Sun, Apr 10, 2016 at 10:25 PM, Ben Pfaff wrote: > > >> No, I'm talking about the rest of the comment, please read it again. > > >> The difference between 1000 vs 1024 bits is a trivial 2.4% difference. > > >> > > >> On Sun, Apr 10, 2016 at 09:46:28PM +0200, Sławek Kapłoński wrote: > > >>> Hello, > > >>> > > >>> Thx for anwear and checking that. AFAIU You are talking about issue > with SI > > >>> and IEC units and problem with it. > > >>> I'm not talking about such issue or not issue. What I pointed here > is that > > >>> (from comment in ovs code) ovs is doing something like: > > >>> "sbin/tc filter add dev parent : protocol all prio 49 > basic > > >>> police rate kbit burst k > > >>> " > > >>> please note this k > > >>> but problem is that when You give "k" to tc it is not kilobits but > kiloBYTES. > > >>> So ovs should do something like " burst kbit" in > this > > >>> command. Or maybe it is intentional to use "k" there so IMHO message > in > > >>> comment should be something like "... burst k" > > >>> > > >>> -- > > >>> Pozdrawiam / Best regards > > >>> Sławek Kapłoński > > >>> sla...@kaplonski.pl > > >>> > > >>> Dnia niedziela, 10 kwietnia 2016 12:36:46 CEST Ben Pfaff pisze: > > >>> > On Thu, Apr 07, 2016 at 09:28:50PM +0200, Sławek Kapłoński wrote: > > >>> > > Hello, > > >>> > > > > >>> > > I'm playing littlebit with ingress policing in openvswitch and I > found > > >>> > > some > > >>> > > kind of inconsistency. > > >>> > > In docs and in source code > > >>> > > (https://github.com/openvswitch/ovs/blob/master/ > > >>> > > lib/netdev-linux.c#L4698) there is info that burst is set in > kilobits, but > > >>> > > I found that in fact it is set in kilobytes in tc. > > >>> > > So long story short: > > >>> > > > > >>> > > root@ubuntu-1604-test:/home/ubuntu# ovs-vsctl show > > >>> > > f0d1f90d-174f-47bf-89bc-bf37f2da0271 > > >>> > > > > >>> > > Bridge "br1" > > >>> > > > > >>> > > Port vethA > > >>> > > > > >>> > > Interface vethA > > >>> > > > > >>> > > Port "br1" > > >>> > > > > >>> > > Interface "br1" > > >>> > > > > >>> > >
Re: [ovs-dev] [PATCH] netdev-linux: Fix ingress policing burst rate configuration via tc
I verified the 10% / 80% changes with netperf, it's unable to sustain 10Mbps without at least a 8Mbit burst. I've seen recommendations from cisco to use policing bursts of around 150 to 200%, but I guess that depends on the path latency or even the implementation. My netperf tests were in-host. On Wed, Apr 13, 2016 at 12:44 PM, Miguel Angel Ajo wrote: > The tc_police structure was filled with a value calculated in bits > instead of bytes while bytes were expected. This led the setting > of an x8 higher burst value. > > Documentation and defaults have been corrected acordingly to minimize > nuisances on users sticking to the defaults. > > The suggested burst value is now 80% of policing rate to make sure > TCP works correctly. > > Signed-off-by: Miguel Angel Ajo > Tested-by: Miguel Angel Ajo > --- > FAQ.md | 2 +- > lib/netdev-linux.c | 14 -- > vswitchd/vswitch.xml | 4 ++-- > 3 files changed, 7 insertions(+), 13 deletions(-) > > diff --git a/FAQ.md b/FAQ.md > index 04ffc84..7dcdb4c 100644 > --- a/FAQ.md > +++ b/FAQ.md > @@ -1124,7 +1124,7 @@ A: A policing policy can be configured on an interface > to drop packets > generate to 10Mbps: > > ovs-vsctl set interface vif1.0 ingress_policing_rate=1 > - ovs-vsctl set interface vif1.0 ingress_policing_burst=1000 > + ovs-vsctl set interface vif1.0 ingress_policing_burst=8000 > > Traffic policing can interact poorly with some network protocols and > can have surprising results. The "Ingress Policing" section of > diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c > index a7d7ac7..a2b6b8a 100644 > --- a/lib/netdev-linux.c > +++ b/lib/netdev-linux.c > @@ -2045,7 +2045,7 @@ netdev_linux_set_policing(struct netdev *netdev_, > int error; > > kbits_burst = (!kbits_rate ? 0 /* Force to 0 if no rate specified. > */ > - : !kbits_burst ? 1000 /* Default to 1000 kbits if 0. */ > + : !kbits_burst ? 8000 /* Default to 8000 kbits if 0. */ > : kbits_burst); /* Stick with user-specified value. > */ > > ovs_mutex_lock(&netdev->mutex); > @@ -4720,21 +4720,15 @@ tc_add_policer(struct netdev *netdev, > tc_police.mtu = mtu; > tc_fill_rate(&tc_police.rate, ((uint64_t) kbits_rate * 1000)/8, mtu); > > -/* The following appears wrong in two ways: > - * > - * - tc_bytes_to_ticks() should take "bytes" as quantity for both of its > - * arguments (or at least consistently "bytes" as both or "bits" as > - * both), but this supplies bytes for the first argument and bits for > the > - * second. > - * > - * - In networking a kilobit is usually 1000 bits but this uses 1024 > bits. > +/* The following appears wrong in one way: In networking a kilobit is > + * usually 1000 bits but this uses 1024 bits. > * > * However if you "fix" those problems then "tc filter show ..." shows > * "125000b", meaning 125,000 bits, when OVS configures it for 1000 kbit > == > * 1,000,000 bits, whereas this actually ends up doing the right thing > from > * tc's point of view. Whatever. */ > tc_police.burst = tc_bytes_to_ticks( > -tc_police.rate.rate, MIN(UINT32_MAX / 1024, kbits_burst) * 1024); > +tc_police.rate.rate, MIN(UINT32_MAX / 1024, kbits_burst) * 1024 / 8); > > tcmsg = tc_make_request(netdev, RTM_NEWTFILTER, > NLM_F_EXCL | NLM_F_CREATE, &request); > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml > index 7d6976f..fca238d 100644 > --- a/vswitchd/vswitch.xml > +++ b/vswitchd/vswitch.xml > @@ -2434,7 +2434,7 @@ > > > Maximum burst size for data received on this interface, in kb. > The > -default burst size if set to 0 is 1000 kb. This value > +default burst size if set to 0 is 8000 kbit. This value > has no effect if > is 0. > > @@ -2442,7 +2442,7 @@ >which is important for protocols like TCP that react severely to >dropped packets. The burst size should be at least the size of the >interface's MTU. Specifying a value that is numerically at least > as > - large as 10% of helps TCP > come > + large as 80% of helps TCP > come >closer to achieving the full rate. > > > -- > 1.8.3.1 > > This patch fixes the burst setting of the ingress policing on netdev-linux, > and > corrects the documentation recommendations accordingly. >
Re: [ovs-dev] [PATCH] netdev-linux: Fix ingress policing burst rate configuration via tc
Ouch, I wonder what happened. I will retry, sorry about it. On Thu, Apr 14, 2016 at 1:08 AM, Ben Pfaff wrote: > Thanks for working on this. The original patch, as opposed to the > followup quoted below) doesn't seem to have made it to the mailing list > archive or to patchwork. Can you resend it? > > On Wed, Apr 13, 2016 at 12:49:28PM +0200, Miguel Angel Ajo Pelayo wrote: >> I verified the 10% / 80% changes with netperf, it's unable to sustain 10Mbps >> without at least a 8Mbit burst. I've seen recommendations from cisco to use >> policing bursts of around 150 to 200%, but I guess that depends on the path >> latency or even the implementation. >> >> My netperf tests were in-host. >> >> >> >> On Wed, Apr 13, 2016 at 12:44 PM, Miguel Angel Ajo >> wrote: >> > The tc_police structure was filled with a value calculated in bits >> > instead of bytes while bytes were expected. This led the setting >> > of an x8 higher burst value. >> > >> > Documentation and defaults have been corrected acordingly to minimize >> > nuisances on users sticking to the defaults. >> > >> > The suggested burst value is now 80% of policing rate to make sure >> > TCP works correctly. >> > >> > Signed-off-by: Miguel Angel Ajo >> > Tested-by: Miguel Angel Ajo >> > --- >> > FAQ.md | 2 +- >> > lib/netdev-linux.c | 14 -- >> > vswitchd/vswitch.xml | 4 ++-- >> > 3 files changed, 7 insertions(+), 13 deletions(-) >> > >> > diff --git a/FAQ.md b/FAQ.md >> > index 04ffc84..7dcdb4c 100644 >> > --- a/FAQ.md >> > +++ b/FAQ.md >> > @@ -1124,7 +1124,7 @@ A: A policing policy can be configured on an >> > interface to drop packets >> > generate to 10Mbps: >> > >> > ovs-vsctl set interface vif1.0 ingress_policing_rate=1 >> > - ovs-vsctl set interface vif1.0 ingress_policing_burst=1000 >> > + ovs-vsctl set interface vif1.0 ingress_policing_burst=8000 >> > >> > Traffic policing can interact poorly with some network protocols and >> > can have surprising results. The "Ingress Policing" section of >> > diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c >> > index a7d7ac7..a2b6b8a 100644 >> > --- a/lib/netdev-linux.c >> > +++ b/lib/netdev-linux.c >> > @@ -2045,7 +2045,7 @@ netdev_linux_set_policing(struct netdev *netdev_, >> > int error; >> > >> > kbits_burst = (!kbits_rate ? 0 /* Force to 0 if no rate >> > specified. */ >> > - : !kbits_burst ? 1000 /* Default to 1000 kbits if 0. */ >> > + : !kbits_burst ? 8000 /* Default to 8000 kbits if 0. */ >> > : kbits_burst); /* Stick with user-specified >> > value. */ >> > >> > ovs_mutex_lock(&netdev->mutex); >> > @@ -4720,21 +4720,15 @@ tc_add_policer(struct netdev *netdev, >> > tc_police.mtu = mtu; >> > tc_fill_rate(&tc_police.rate, ((uint64_t) kbits_rate * 1000)/8, mtu); >> > >> > -/* The following appears wrong in two ways: >> > - * >> > - * - tc_bytes_to_ticks() should take "bytes" as quantity for both of >> > its >> > - * arguments (or at least consistently "bytes" as both or "bits" as >> > - * both), but this supplies bytes for the first argument and bits >> > for the >> > - * second. >> > - * >> > - * - In networking a kilobit is usually 1000 bits but this uses 1024 >> > bits. >> > +/* The following appears wrong in one way: In networking a kilobit is >> > + * usually 1000 bits but this uses 1024 bits. >> > * >> > * However if you "fix" those problems then "tc filter show ..." shows >> > * "125000b", meaning 125,000 bits, when OVS configures it for 1000 >> > kbit == >> > * 1,000,000 bits, whereas this actually ends up doing the right >> > thing from >> > * tc's point of view. Whatever. */ >> > tc_police.burst = tc_bytes_to_ticks( >> > -tc_police.rate.rate, MIN(UINT32_MAX / 1024, kbits_burst) * 1024); >> > +tc_police.rate.rate, MIN(UINT32_MAX / 1024, kbits_burst) * 1024 / >> > 8); >> > >> > tcmsg = tc_make_request(netdev, RTM_NEWTFILTER, >> >
Re: [ovs-dev] header files in the connection-tracking branch
I’m using this script to build on Centos7: $ cat ovs-install.sh #!/bin/sh set -e set -x OVS_GIT=https://github.com/justinpettit/ovs.git OVS_BRANCH=conntrack # openvswitch specifics sudo yum -y install openssl-devel libtool rpm-build gcc g++ kernel-headers \ kernel-devel python-twisted-core python-zope-interface \ PyQt4 desktop-file-utils groff graphviz git clone $OVS_GIT ovs || echo already cloned cd ovs git checkout $OVS_BRANCH || echo can\'t checkout branch # create dist files ./boot.sh ./configure --prefix=/usr rm -rf openvswitch*.tar.gz make dist mkdir -p ~/rpmbuild/SOURCES cp openvswitch-*.tar.gz $HOME/rpmbuild/SOURCES sudo setenforce 0 sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config sudo service openvswitch stop || echo couldn\'t stop # build userland rm -rf build mkdir build cd build tar xvfz ../*tar.gz cd openvswitch-* sed -i 's/Requires: kernel >= 3.15.0-0/Requires: kernel >= 3.10.0-0/g' rhel/openvswitch-fedora.spec rpmbuild -bb --without check rhel/openvswitch-fedora.spec sudo yum install -y /home/centos/rpmbuild/RPMS/x86_64/openvswitch* || \ sudo yum reinstall -y /home/centos/rpmbuild/RPMS/x86_64/openvswitch* # build kernel sudo sed -i 's/enabled=0/enabled=1/g' /etc/yum.repos.d/CentOS-Sources.repo yumdownloader --source kernel rpm -i --force kernel*.rpm export KVERSION=$(uname -r) rpmbuild -bb rhel/openvswitch-kmod-fedora.spec -D "kversion $KVERSION" sudo yum install -y /home/centos/rpmbuild/RPMS/x86_64/openvswitch-kmod* || \ sudo yum reinstall -y /home/centos/rpmbuild/RPMS/x86_64/openvswitch-kmod* sudo rmmod openvswitch || echo ok sudo modprobe nf_conntrack sudo modprobe nf_conntrack_netlink sudo modprobe gre sudo insmod /lib/modules/$KVERSION/kernel/extra/openvswitch/openvswitch.ko > On 21/4/2015, at 2:28, pclin wrote: > > Dear all, > > We are reading the source code in the private branch > https://github.com/justinpettit/ovs/tree/conntrack, > and find that some of the header files, such as > net/netfilter/nf_conntrack_helper.h in conntrack.c, seem > to be outdated (my apology if there is any misunderstanding). For example, > the header file > net/netfilter/nf_conntrack_helper.h becomes > linux/netfilter/nfnetlink_cthelper.h in linux-header-3.13.0.49 > recently distributed on Ubuntu 14.04. Will the branch be adapted to the > change in the new netfilter interfaces? > If not, please suggest the Linux distribution (and version) on which we can > build and try the source code in > the branch. Thanks a lot. > > Po-Ching > ___________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev Miguel Angel Ajo ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
