Re: [ovs-discuss] OVS/OVN docker image for each stable release
On Wed, Nov 13, 2019 at 12:02 AM Shivaram Mysore wrote: > > No need to indicate "built on Ubuntu" for docker image tags. > Alpine tag is specifically used as it used different libraries and image size > is small. Ideally, for Docker images, we should use Alpine Linux. If OVS > for Alpine is latest, then image size will be further reduced. > > Note thAt at the end of the day, container is just a delivery or packaging > vehicle. > > /Shivaram > ::Sent from my mobile device:: > > On Nov 12, 2019, at 9:49 AM, aginwala wrote: > > > Thanks Shivaram: > > On Tue, Nov 12, 2019 at 9:28 AM Shivaram Mysore > wrote: >> >> I am not sure why "*_debian" is used. The image should work across OS. I >> have not seen use of "*_linux" as most docker images use some form of >> shell scripts. >> > Because the container image published is ubuntu and hence we tagged it with > _debian. It doesn't indicate it will not work on rhel. If we all agree we can > remove the tags and update the readme.md on docker.io that each container > image is using ubuntu as base image. I am fine with any approach. >> >> Also, in my opinion, the docker image should not build OVS. If it can add >> appropriate OVS packages like >> https://github.com/servicefractal/ovs/blob/master/Dockerfile is better as >> they are already tested. Building OVS as a part of this will cause more >> testing impacts and is unnecessary. The objective is to run OVS in a >> container image. I would keep it simple. I think the idea was to have an OVS container image with the latest master code right Aliasgar ? Getting OVS packages is good, but then the debian/ubuntu/fedora packages should be updated as soon as OVS does a release. Thanks Numan >> > I think the objective is to have an image per upstream stable ovs release and > hence building it in container. Hope everyone is ok here. >> >> On Tue, Nov 12, 2019 at 12:51 AM aginwala wrote: >>> >>> Thanks Guru. >>> >>> On Mon, Nov 11, 2019 at 1:03 PM Guru Shetty wrote: On Mon, 11 Nov 2019 at 10:08, aginwala wrote: > > > > On Mon, Nov 11, 2019 at 9:00 AM Guru Shetty wrote: >> >> >> >> On Fri, 8 Nov 2019 at 14:41, aginwala wrote: >>> >>> openvswitch.ko ships default with newer kernel but if we want to use >>> say stt, we need to build it with respective kernel for host on which >>> we will run. Hence, to skip host level installation , we pack the >>> modules in container. >> >> >> It is not clear to me. Is DKMS enabled here? Or is it that >> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic will only work on kernel >> 4.15.0-66-generic? >> > > No. Dkms is not enabled because idea is to release a new docker image for > every new kernel upgrade on compute (Not sure if dkms will help much in > container case as we are not installing on host). Do you have any > specific use case which? Yes on host with 4.15.0-66-generic. It will probably be very hard to release each OVS version to so many available kernels. How do you decide which kernel that you want to release a image for? What is the plan here? I think it makes sense to release one image without a kernel module packed with it. >>> Agree, we can't publish too many images based on different kernel versions. >>> Hence, I am ok with the approach you proposed by publishing single image >>> for each stable release leveraging host kernel modules. I have pushed 2 >>> debian images for each stable releases 2.11.2_debian and 2.12.0_debian >>> under openvswitch/ovs accordingly. I also sent the corresponding patch >>> https://patchwork.ozlabs.org/patch/1193372/ to refactor the docker builds >>> to support an option to skip kernel modules for ovs repo so that user can >>> choose to build/run with/without kernel modules. Let me know further. >>> >>> >>> >>> On Fri, Nov 8, 2019 at 2:37 PM Guru Shetty wrote: On Fri, 8 Nov 2019 at 14:18, aginwala wrote: > > Hi all: > > > I have pushed two images to public openvswitch org on docker.io for > ovs and ovn; > OVS for ubuntu with 4.15 kernel: > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic Why is the kernel important here? Is the OVS kernel module being packed? > > run as : docker run -itd --net=host --name=ovsdb-server > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovsdb-server > docker run -itd --net=host > --name=ovs-vswitchd --volumes-from=ovsdb-server --privileged > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovs-vswitchd > > OVN debian docker image: openvswitch/ovn:2.12_e60f2f2_debian_master > as we don't have a branch cut out for ovn yet. (Hence, tagged
Re: [ovs-discuss] skipping output to input port
> Sometimes, icmpv6 neighbor advertisement packets are being sent out of the > hypervisor without their VLAN tag. It seems to only happens when the icmpv6 > is sent to a multicast address. That doesn't happen to every VMs, and not > all the > I meant Neighbor Solicitation ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] skipping output to input port
Sometimes, icmpv6 neighbor advertisement packets are being sent out of the hypervisor without their VLAN tag. It seems to only happens when the icmpv6 is sent to a multicast address. That doesn't happen to every VMs, and not all the time. Can't reproduce the problem on demand yet. I'm trying to better understand what the log message "skipping output to input port" really means. Because every time a packet is sent without a VLAN tag, we also see this printed in the log. Normally, these packets are being VLAN tagged, and when we ofproto/trace, we see that the packet should be tagged. 2019-11-12T21:06:13.838Z|01842|ofproto_dpif_xlate(handler148)|INFO|skipping output to input port on bridge br0 while processing recirc_id=0x5a4de60,ct_state=inv|trk,eth,icmp6,in_port=10227,vlan_tci=0x,dl_src=6a:5e:dd:34:f9:be,dl_dst=33:33:ff:25:80:0b,ipv6_src=fe80::685e:ddff:fe34:f9be,ipv6_dst=ff02::1:ff25:800b,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,icmp_type=135,icmp_code=0,nd_target=2604::x:xx::xx:,nd_sll=6a:5e:dd:34:f9:be,nd_tll=00:00:00:00:00:00 I read https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-xlate.c but yet I'm not sure I fully grasp what it means. Also, since it's intermittent, seems like there is something dynamic. Looked at the connection tracking, and also at the ovs/show/route cache... but haven't figured yet. thanks ! ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Custom template fields with IPFIX
Hi, I'm trying to setup custom IPFIX export field that include a custom metadata field loaded from the ovs flow register. I have successfully setup ipfix sampling with a flow sample action but I can't get a custom field to be exported. Looking at the docs there is an `external_ids` field, which is a map of string to string, but I can't seem to get that to work. Essentially I need the normal data record export(which I have working) plus the extra field which I would like to load from reg2. Would this be possible? I've tried digging through ipfix/ovs docs but haven't found a solution yet. Thank you in advance for your help. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS/OVN docker image for each stable release
No need to indicate "built on Ubuntu" for docker image tags. Alpine tag is specifically used as it used different libraries and image size is small. Ideally, for Docker images, we should use Alpine Linux. If OVS for Alpine is latest, then image size will be further reduced. Note thAt at the end of the day, container is just a delivery or packaging vehicle. /Shivaram ::Sent from my mobile device:: > On Nov 12, 2019, at 9:49 AM, aginwala wrote: > > > Thanks Shivaram: > >> On Tue, Nov 12, 2019 at 9:28 AM Shivaram Mysore >> wrote: >> I am not sure why "*_debian" is used. The image should work across OS. I >> have not seen use of "*_linux" as most docker images use some form of >> shell scripts. >> > Because the container image published is ubuntu and hence we tagged it with > _debian. It doesn't indicate it will not work on rhel. If we all agree we can > remove the tags and update the readme.md on docker.io that each container > image is using ubuntu as base image. I am fine with any approach. >> Also, in my opinion, the docker image should not build OVS. If it can add >> appropriate OVS packages like >> https://github.com/servicefractal/ovs/blob/master/Dockerfile is better as >> they are already tested. Building OVS as a part of this will cause more >> testing impacts and is unnecessary. The objective is to run OVS in a >> container image. I would keep it simple. >> > I think the objective is to have an image per upstream stable ovs release and > hence building it in container. Hope everyone is ok here. >>> On Tue, Nov 12, 2019 at 12:51 AM aginwala wrote: >>> Thanks Guru. >>> > On Mon, Nov 11, 2019 at 1:03 PM Guru Shetty wrote: > > >> On Mon, 11 Nov 2019 at 10:08, aginwala wrote: >> >> >>> On Mon, Nov 11, 2019 at 9:00 AM Guru Shetty wrote: >>> >>> On Fri, 8 Nov 2019 at 14:41, aginwala wrote: openvswitch.ko ships default with newer kernel but if we want to use say stt, we need to build it with respective kernel for host on which we will run. Hence, to skip host level installation , we pack the modules in container. >>> >>> It is not clear to me. Is DKMS enabled here? Or is it that >>> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic will only work on >>> kernel 4.15.0-66-generic? >>> >> No. Dkms is not enabled because idea is to release a new docker image >> for every new kernel upgrade on compute (Not sure if dkms will help much >> in container case as we are not installing on host). Do you have any >> specific use case which? Yes on host with 4.15.0-66-generic. > > It will probably be very hard to release each OVS version to so many > available kernels. How do you decide which kernel that you want to > release a image for? What is the plan here? I think it makes sense to > release one image without a kernel module packed with it. > Agree, we can't publish too many images based on different kernel versions. Hence, I am ok with the approach you proposed by publishing single image for each stable release leveraging host kernel modules. I have pushed 2 debian images for each stable releases 2.11.2_debian and 2.12.0_debian under openvswitch/ovs accordingly. I also sent the corresponding patch https://patchwork.ozlabs.org/patch/1193372/ to refactor the docker builds to support an option to skip kernel modules for ovs repo so that user can choose to build/run with/without kernel modules. Let me know further. >>> On Fri, Nov 8, 2019 at 2:37 PM Guru Shetty wrote: > On Fri, 8 Nov 2019 at 14:18, aginwala wrote: > Hi all: > > > I have pushed two images to public openvswitch org on docker.io for > ovs and ovn; > OVS for ubuntu with 4.15 kernel: > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic Why is the kernel important here? Is the OVS kernel module being packed? > run as : docker run -itd --net=host --name=ovsdb-server > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovsdb-server > docker run -itd --net=host > --name=ovs-vswitchd --volumes-from=ovsdb-server --privileged > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovs-vswitchd > > OVN debian docker image: openvswitch/ovn:2.12_e60f2f2_debian_master > as we don't have a branch cut out for ovn yet. (Hence, tagged it with > last commit on master) > Follow steps as per: > https://github.com/ovn-org/ovn/blob/master/Documentation/intro/install/general.rst > > > Thanks Guru for sorting out the access/cleanups for openvswitch org > on docker.io. > > We can
Re: [ovs-discuss] OVS/OVN docker image for each stable release
Thanks Shivaram: On Tue, Nov 12, 2019 at 9:28 AM Shivaram Mysore wrote: > I am not sure why "*_debian" is used. The image should work across OS. > I have not seen use of "*_linux" as most docker images use some form of > shell scripts. > > Because the container image published is ubuntu and hence we tagged it with _debian. It doesn't indicate it will not work on rhel. If we all agree we can remove the tags and update the readme.md on docker.io that each container image is using ubuntu as base image. I am fine with any approach. > Also, in my opinion, the docker image should not build OVS. If it can add > appropriate OVS packages like > https://github.com/servicefractal/ovs/blob/master/Dockerfile is better as > they are already tested. Building OVS as a part of this will cause more > testing impacts and is unnecessary. The objective is to run OVS in a > container image. I would keep it simple. > > I think the objective is to have an image per upstream stable ovs release and hence building it in container. Hope everyone is ok here. > On Tue, Nov 12, 2019 at 12:51 AM aginwala wrote: > >> Thanks Guru. >> >> On Mon, Nov 11, 2019 at 1:03 PM Guru Shetty wrote: >> >>> >>> >>> On Mon, 11 Nov 2019 at 10:08, aginwala wrote: >>> On Mon, Nov 11, 2019 at 9:00 AM Guru Shetty wrote: > > > On Fri, 8 Nov 2019 at 14:41, aginwala wrote: > >> openvswitch.ko ships default with newer kernel but if we want to use >> say stt, we need to build it with respective kernel for host on which we >> will run. Hence, to skip host level installation , we pack the modules in >> container. >> > > It is not clear to me. Is DKMS enabled here? Or is it that > openvswitch/ovs:2.12.0_debian_4.15.0-66-generic will only work on > kernel 4.15.0-66-generic? > > No. Dkms is not enabled because idea is to release a new docker image for every new kernel upgrade on compute (Not sure if dkms will help much in container case as we are not installing on host). Do you have any specific use case which? Yes on host with 4.15.0-66-generic. >>> >>> It will probably be very hard to release each OVS version to so many >>> available kernels. How do you decide which kernel that you want to release >>> a image for? What is the plan here? I think it makes sense to release one >>> image without a kernel module packed with it. >>> >>> Agree, we can't publish too many images based on different kernel >> versions. Hence, I am ok with the approach you proposed by publishing >> single image for each stable release leveraging host kernel modules. I have >> pushed 2 debian images for each stable releases 2.11.2_debian and >> 2.12.0_debian under openvswitch/ovs accordingly. I also sent the >> corresponding patch https://patchwork.ozlabs.org/patch/1193372/ to >> refactor the docker builds to support an option to skip kernel modules for >> ovs repo so that user can choose to build/run with/without kernel modules. >> Let me know further. >> >> >>> >>> >> On Fri, Nov 8, 2019 at 2:37 PM Guru Shetty wrote: >> >>> >>> >>> On Fri, 8 Nov 2019 at 14:18, aginwala wrote: >>> Hi all: I have pushed two images to public openvswitch org on docker.io for ovs and ovn; OVS for ubuntu with 4.15 kernel: *openvswitch/ovs:2.12.0_debian_4.15.0-66-generic* >>> >>> Why is the kernel important here? Is the OVS kernel module being >>> packed? >>> >>> run as : docker run -itd --net=host --name=ovsdb-server openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovsdb-server docker run -itd --net=host --name=ovs-vswitchd --volumes-from=ovsdb-server --privileged openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovs-vswitchd OVN debian docker image: *openvswitch/ovn:2.12_e60f2f2_debian_master* as we don't have a branch cut out for ovn yet. (Hence, tagged it with last commit on master) Follow steps as per: https://github.com/ovn-org/ovn/blob/master/Documentation/intro/install/general.rst Thanks Guru for sorting out the access/cleanups for openvswitch org on docker.io. We can plan to align this docker push for each stable release ahead. On Fri, Nov 8, 2019 at 10:17 AM aginwala wrote: > Thanks Guru: > > Sounds good. Can you please grant user aginwala as admin? I can > create two repos ovs and ovn under openvswitch org and can push new > stable > release versions there. > > On Fri, Nov 8, 2019 at 10:04 AM Guru Shetty wrote: > >> On Fri, 8 Nov 2019 at 09:53, Guru Shetty wrote: >> >>> I had created a openvswitch repo in docker
Re: [ovs-discuss] OVS/OVN docker image for each stable release
I am not sure why "*_debian" is used. The image should work across OS. I have not seen use of "*_linux" as most docker images use some form of shell scripts. Also, in my opinion, the docker image should not build OVS. If it can add appropriate OVS packages like https://github.com/servicefractal/ovs/blob/master/Dockerfile is better as they are already tested. Building OVS as a part of this will cause more testing impacts and is unnecessary. The objective is to run OVS in a container image. I would keep it simple. On Tue, Nov 12, 2019 at 12:51 AM aginwala wrote: > Thanks Guru. > > On Mon, Nov 11, 2019 at 1:03 PM Guru Shetty wrote: > >> >> >> On Mon, 11 Nov 2019 at 10:08, aginwala wrote: >> >>> >>> >>> On Mon, Nov 11, 2019 at 9:00 AM Guru Shetty wrote: >>> On Fri, 8 Nov 2019 at 14:41, aginwala wrote: > openvswitch.ko ships default with newer kernel but if we want to use > say stt, we need to build it with respective kernel for host on which we > will run. Hence, to skip host level installation , we pack the modules in > container. > It is not clear to me. Is DKMS enabled here? Or is it that openvswitch/ovs:2.12.0_debian_4.15.0-66-generic will only work on kernel 4.15.0-66-generic? >>> No. Dkms is not enabled because idea is to release a new docker image >>> for every new kernel upgrade on compute (Not sure if dkms will help much in >>> container case as we are not installing on host). Do you have any specific >>> use case which? Yes on host with 4.15.0-66-generic. >>> >> >> It will probably be very hard to release each OVS version to so many >> available kernels. How do you decide which kernel that you want to release >> a image for? What is the plan here? I think it makes sense to release one >> image without a kernel module packed with it. >> >> Agree, we can't publish too many images based on different kernel > versions. Hence, I am ok with the approach you proposed by publishing > single image for each stable release leveraging host kernel modules. I have > pushed 2 debian images for each stable releases 2.11.2_debian and > 2.12.0_debian under openvswitch/ovs accordingly. I also sent the > corresponding patch https://patchwork.ozlabs.org/patch/1193372/ to > refactor the docker builds to support an option to skip kernel modules for > ovs repo so that user can choose to build/run with/without kernel modules. > Let me know further. > > >> >> >>> > On Fri, Nov 8, 2019 at 2:37 PM Guru Shetty wrote: > >> >> >> On Fri, 8 Nov 2019 at 14:18, aginwala wrote: >> >>> Hi all: >>> >>> >>> I have pushed two images to public openvswitch org on docker.io for >>> ovs and ovn; >>> OVS for ubuntu with 4.15 kernel: >>> *openvswitch/ovs:2.12.0_debian_4.15.0-66-generic* >>> >> >> Why is the kernel important here? Is the OVS kernel module being >> packed? >> >> >>> run as : docker run -itd --net=host --name=ovsdb-server >>> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovsdb-server >>> docker run -itd --net=host >>> --name=ovs-vswitchd --volumes-from=ovsdb-server --privileged >>> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovs-vswitchd >>> >>> OVN debian docker image: >>> *openvswitch/ovn:2.12_e60f2f2_debian_master* as we don't have a >>> branch cut out for ovn yet. (Hence, tagged it with last commit on >>> master) >>> Follow steps as per: >>> https://github.com/ovn-org/ovn/blob/master/Documentation/intro/install/general.rst >>> >>> >>> Thanks Guru for sorting out the access/cleanups for openvswitch org >>> on docker.io. >>> >>> We can plan to align this docker push for each stable release ahead. >>> >>> >>> >>> On Fri, Nov 8, 2019 at 10:17 AM aginwala wrote: >>> Thanks Guru: Sounds good. Can you please grant user aginwala as admin? I can create two repos ovs and ovn under openvswitch org and can push new stable release versions there. On Fri, Nov 8, 2019 at 10:04 AM Guru Shetty wrote: > On Fri, 8 Nov 2019 at 09:53, Guru Shetty wrote: > >> I had created a openvswitch repo in docker as a placeholder. >> Happy to provide it to whoever the admin is. >> > > i.e. You can use the keyword "openvswitch". For e.g., right now, > it has one stale image. > > docker run -d --net=none openvswitch/ipam:v2.4.90 /bin/sh -c > "while true; do echo hello world; sleep 1; done" > > So if we want the name "openvswitch", this is one option. If we > prefer ovs/ovn or other keywords, then the admin can create a new one. > > >> >> On Thu, 7 Nov 2019 at 13:15, aginwala wrote: >> >>> Hi All: >>>
Re: [ovs-discuss] ovs-vswitchd.service crashes
Hello,
I installed the linux-generic-hwe-18.04-edge kernel.
apt list --installed | grep linux-image
linux-image-generic-hwe-18.04-edge/bionic,now 4.18.0.16.65 amd64 [installed]
hwe-support-status - verbose
Your Hardware Enablement Stack (HWE) is supported until April 2023.
Previously reported error when
In a short time after creating several new instances, the service will crash
after capturing this assert
"ovs | 1 | util (handler8) | EMER | ../ include / openvswitch / ofpbuf.h: 190:
assertion offset + size <= b -> size failed inpbuf_at_assert ()"
it is not happening yet.
However, there was another problem.
When creating a new VM, the following error occurs:
in /var/log/openvswitch/ovs-vswitchd.log
2019-11-11T15:54:46.937Z|00108|connmgr|INFO|br-int<->tcp:127.0.0.1:6633: 16
flow_mods in the 4 s starting 10 s ago (12 adds, 4 deletes)
2019-11-11T16:03:53.798Z|1|dpif_netlink(handler7)|ERR|failed to offload
flow: Numerical result out of range: eth51
2019-11-11T16:03:53.810Z|2|dpif_netlink(handler7)|ERR|failed to offload
flow: Numerical result out of range: eth51
2019-11-11T16:03:54.154Z|3|dpif_netlink(handler7)|ERR|failed to offload
flow: Numerical result out of range: eth51
2019-11-11T16:03:55.178Z|4|dpif_netlink(handler7)|ERR|failed to offload
flow: Numerical result out of range: eth51
The status of ovs-vswitchd will end up with a problem with offloading rules.
oot@dev-node1:/usr/share/doc# service ovs-vswitchd status
* ovs-vswitchd.service - Open vSwitch Forwarding Unit
Loaded: loaded (/lib/systemd/system/ovs-vswitchd.service; static; vendor
preset: enabled)
Active: active (running) since Mon 2019-11-11 16:28:43 CET; 36min ago
Process: 26869 ExecStop=/usr/share/openvswitch/scripts/ovs-ctl
--no-ovsdb-server stop (code=exited, status=0/SUCCESS)
Process: 26993 ExecStart=/usr/share/openvswitch/scripts/ovs-ctl
--no-ovsdb-server --no-monitor --system-id=random start $OPTIONS (code=exited,
Main PID: 27037 (ovs-vswitchd)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/ovs-vswitchd.service
`-27037 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vconsole:emer
-vsyslog:err -vfile:info --mlockall --no-chdir --log-file=/var/l
Nov 11 16:28:43 dev-node1 ovs-vsctl[27057]: ovs|1|vsctl|INFO|Called as
ovs-vsctl --no-wait set Open_vSwitch . external-ids:hostname=dev-node1
Nov 11 16:28:43 dev-node1 ovs-ctl[26993]: * Enabling remote OVSDB managers
Nov 11 16:28:43 dev-node1 systemd[1]: Started Open vSwitch Forwarding Unit.
Nov 11 17:03:53 dev-node1 ovs-vswitchd[27037]:
ovs|1|dpif_netlink(handler7)|ERR|failed to offload flow: Numerical result
out of range: eth51
Nov 11 17:03:53 dev-node1 ovs-vswitchd[27037]:
ovs|2|dpif_netlink(handler7)|ERR|failed to offload flow: Numerical result
out of range: eth51
Nov 11 17:03:54 dev-node1 ovs-vswitchd[27037]:
ovs|3|dpif_netlink(handler7)|ERR|failed to offload flow: Numerical result
out of range: eth51
This error does not happen with every VM creation, but it always ends after a
few successfully created VMs.
We have hw-offload turned on
root@dev-node1: ~ # ovs-vsctl get Open_vSwitch. other-config
{hw-offload = "true"}
Thank you for your help.
Petr Koukal
On 11/7/19 10:46 AM, James Page wrote:
Hi Koukal
I note that you're using the 4.18 kernel from Ubuntu; For Mellanox hardware
offload I'd suggest you switch to using the hwe-edge kernel (5.3) as this is
generally more mature for this (and other mlx5_core) feature - package name is
'linux-generic-hwe-18.04-edge'.
On Thu, Nov 7, 2019 at 9:23 AM Koukal Petr
mailto:p.kou...@radiokomunikace.cz>> wrote:
In case I turn off hw-offload with
ovs-vsctl set Open_vSwitch. other-config: hw-offload = false
then "ovs-vswitchd" is without collision.
Is it possible to reach someone who knows what to do with the offload problem?
Thank you for your help.
Petr
On 11/6/19 6:48 PM, Ben Pfaff wrote:
On Wed, Nov 06, 2019 at 01:59:36PM +0100, Koukal Petr wrote:
The problem is the same even if hw-offload is off.
I'm sending a log from ovs-vswitchd.log just after restarting the whole
openvswitch-switch.
Here you can see what happens before the assertion pops up.
ethtool -K phys1-1 hw-tc-offload off
ethtool -K phys1-2 hw-tc-offload off
This demonstrates turning off hardware offload at the ethtool level.
However, even with that, I believe that OVS will still try to use it if
OVS is configured for hardware offload. It looks like your OVS does
have hardware offload enabled. To turn it off, run:
ovs-vsctl set Open_vSwitch . other-config:hw-offload=false
Then restart OVS and see if it makes a difference.
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Informace obsažené v této e-mailové zprávě a všech přiložených souborech jsou
důvěrné a jsou určeny pouze pro potřebu adresáta. Prosíme, abyste v případě, že
tento e-mail
Re: [ovs-discuss] OVS/OVN docker image for each stable release
Thanks Guru. On Mon, Nov 11, 2019 at 1:03 PM Guru Shetty wrote: > > > On Mon, 11 Nov 2019 at 10:08, aginwala wrote: > >> >> >> On Mon, Nov 11, 2019 at 9:00 AM Guru Shetty wrote: >> >>> >>> >>> On Fri, 8 Nov 2019 at 14:41, aginwala wrote: >>> openvswitch.ko ships default with newer kernel but if we want to use say stt, we need to build it with respective kernel for host on which we will run. Hence, to skip host level installation , we pack the modules in container. >>> >>> It is not clear to me. Is DKMS enabled here? Or is it that >>> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic will only work on >>> kernel 4.15.0-66-generic? >>> >>> >> No. Dkms is not enabled because idea is to release a new docker image for >> every new kernel upgrade on compute (Not sure if dkms will help much in >> container case as we are not installing on host). Do you have any specific >> use case which? Yes on host with 4.15.0-66-generic. >> > > It will probably be very hard to release each OVS version to so many > available kernels. How do you decide which kernel that you want to release > a image for? What is the plan here? I think it makes sense to release one > image without a kernel module packed with it. > > Agree, we can't publish too many images based on different kernel versions. Hence, I am ok with the approach you proposed by publishing single image for each stable release leveraging host kernel modules. I have pushed 2 debian images for each stable releases 2.11.2_debian and 2.12.0_debian under openvswitch/ovs accordingly. I also sent the corresponding patch https://patchwork.ozlabs.org/patch/1193372/ to refactor the docker builds to support an option to skip kernel modules for ovs repo so that user can choose to build/run with/without kernel modules. Let me know further. > > >> On Fri, Nov 8, 2019 at 2:37 PM Guru Shetty wrote: > > > On Fri, 8 Nov 2019 at 14:18, aginwala wrote: > >> Hi all: >> >> >> I have pushed two images to public openvswitch org on docker.io for >> ovs and ovn; >> OVS for ubuntu with 4.15 kernel: >> *openvswitch/ovs:2.12.0_debian_4.15.0-66-generic* >> > > Why is the kernel important here? Is the OVS kernel module being > packed? > > >> run as : docker run -itd --net=host --name=ovsdb-server >> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovsdb-server >> docker run -itd --net=host >> --name=ovs-vswitchd --volumes-from=ovsdb-server --privileged >> openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovs-vswitchd >> >> OVN debian docker image: >> *openvswitch/ovn:2.12_e60f2f2_debian_master* as we don't have a >> branch cut out for ovn yet. (Hence, tagged it with last commit on master) >> Follow steps as per: >> https://github.com/ovn-org/ovn/blob/master/Documentation/intro/install/general.rst >> >> >> Thanks Guru for sorting out the access/cleanups for openvswitch org >> on docker.io. >> >> We can plan to align this docker push for each stable release ahead. >> >> >> >> On Fri, Nov 8, 2019 at 10:17 AM aginwala wrote: >> >>> Thanks Guru: >>> >>> Sounds good. Can you please grant user aginwala as admin? I can >>> create two repos ovs and ovn under openvswitch org and can push new >>> stable >>> release versions there. >>> >>> On Fri, Nov 8, 2019 at 10:04 AM Guru Shetty wrote: >>> On Fri, 8 Nov 2019 at 09:53, Guru Shetty wrote: > I had created a openvswitch repo in docker as a placeholder. Happy > to provide it to whoever the admin is. > i.e. You can use the keyword "openvswitch". For e.g., right now, it has one stale image. docker run -d --net=none openvswitch/ipam:v2.4.90 /bin/sh -c "while true; do echo hello world; sleep 1; done" So if we want the name "openvswitch", this is one option. If we prefer ovs/ovn or other keywords, then the admin can create a new one. > > On Thu, 7 Nov 2019 at 13:15, aginwala wrote: > >> Hi All: >> >> As discussed in the meeting today, we all agreed that it will be >> a good idea to push docker images for each new ovs/ovn stable >> release. >> Hence, need help from maintainers Ben/Mark/Justin/Han to address >> some open >> action items as it is more of org/ownership/rights related: >> >>1. Get new repo created under docker.io with name either >>ovs/ovn and declare it public repo >>2. How about copy-rights for running images for open source >>projects >>3. Storage: unlimited or some limited GBs >>4. Naming conventions for docker images ;e.g >>openswitch/ovn:2.13.1_debian or
[ovs-discuss] regarding trunc feature changes for OVS_ACTION_ATTR_USERSPACE
Hi ,
i am not getting reason,why highlighted code is added for
OVS_ACTION_ATTR_USERSPACE.
What purpose it serves.
This code got added as part of feature "ofp-actions: Add truncate
action. The patch adds a new action to support packet truncation. "
Can somebody please help in understanding below part?
file :"lib/dpif-netdev.c"
function : dp_execute_cb
case OVS_ACTION_ATTR_USERSPACE:
.
.
.
userdata = nl_attr_find_nested(a, OVS_USERSPACE_ATTR_USERDATA);
ofpbuf_init(, 0);
* if (packets_->trunc) {if (!should_steal) {
dp_packet_batch_clone(_pkt, packets_);packets_
= _pkt;clone = true;
dp_packet_batch_reset_cutlen(orig_packets_);}
dp_packet_batch_apply_cutlen(packets_);*
}
return;
}
break;
regards,
Bindiya
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
