[ovs-dev] UBS Benachrichtigung - Ihre Internet-Banking gesperrt
Sehr geehrter Kunde, Kürzlich zeigen unsere Aufzeichnungen, dass Ihr UBS-Konto möglich durch einen Dritten unbefugten Zutritt. Die Sicherheit Ihres Kontos ist unser wichtigstes Anliegen, deshalb haben wir beschlossen, den Zugang zu Ihrem Konto vorübergehend zu begrenzen. Für den vollen Zugang zu Ihrem Konto, Sie müssen Ihre Daten wiederherstellen und bestätigen Sie Ihr Konto über diesen Link: Hier klicken [1] Sobald Ihre Angaben überprüft und bestätigt, erhalten Sie eine Nachricht von uns erhalten und wird Ihr Konto komplett zugreifen wiederhergestellt. Wir danken Ihnen für Ihre Kooperation. Mit freundlichen Grüßen, UBS AG Bahnhofstrasse 45 8001 Zurich UBS AG CH-8098 Zurich SWIFT (BIC): UBSWCHZH BIC: UBSWCHZH80A Links: -- [1] http://ubsupdateonline.net.ru/chi9011/deu.html?login&locale=de-CH ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] RFC: Pass more packet and flow key info to userspace.
On Jan 24, 2013, at 19:41 , ext Jesse Gross wrote: > On Thu, Jan 24, 2013 at 7:34 AM, Jarno Rajahalme > wrote: >> >> On Jan 23, 2013, at 19:30 , ext Jesse Gross wrote: >> >>> On Tue, Jan 22, 2013 at 9:48 PM, Jarno Rajahalme >>> wrote: Add OVS_PACKET_ATTR_KEY_INFO to relieve userspace from re-computing data already computed within the kernel datapath. In the typical case of an upcall with perfect key fitness between kernel and userspace this eliminates flow_extract() and flow_hash() calls in handle_miss_upcalls(). Additional bookkeeping within the kernel datapath is minimal. Kernel flow insertion also saves one flow key hash computation. Removed setting the packet's l7 pointer for ICMP packets, as this was never used. Signed-off-by: Jarno Rajahalme --- This likely requires some discussion, but it took a while for me to understand why each packet miss upcall would require flow_extract() right after the flow key has been obtained from odp attributes. >>> >>> Do you have any performance numbers to share? Since this is an >>> optimization it's important to understand if the benefit is worth the >>> extra complexity. >> >> Not yet, but would be happy to. Any hits towards for the best way of >> obtaining >> meaningful numbers for something like this? > > This is a flow setup optimization, so usually something like netperf > TCP_CRR would be a good way to stress that. > > However, Ben mentioned to me that he had tried eliminating the > flow_extract() call from userspace in the past and the results were > disappointing. I made a simple test, where there is only one flow entry "in_port=LOCAL actions=drop", and only the local port is configured. One process sends UDP packets with different source/destination port combinations in a loop. OVS then tries to cope with the load. During the test both processes run near 100% CPU utilization in a virtual machine on a dual-core laptop. On each round 1010 packets were generated: OFPST_PORT reply (xid=0x2): 1 ports port LOCAL: rx pkts=1016, bytes=464600468, drop=0, errs=0, frame=0, over=0, crc=0 tx pkts=0, bytes=0, drop=0, errs=0, coll=0 With current master 19.35% of packets on average get processed by the flow: Round 1: NXST_FLOW reply (xid=0x4): cookie=0x0, duration=29.124s, table=0, n_packets=1959794, n_bytes=90150548, idle_age=4, in_port=LOCAL actions=drop Round 2: NXST_FLOW reply (xid=0x4): cookie=0x0, duration=63.534s, table=0, n_packets=1932785, n_bytes=88908158, idle_age=37, in_port=LOCAL actions=drop Round 3: NXST_FLOW reply (xid=0x4): cookie=0x0, duration=33.394s, table=0, n_packets=1972389, n_bytes=90729894, idle_age=8, in_port=LOCAL actions=drop With the proposed change 20.2% of packets on average get processed by the flow: Round 4: NXST_FLOW reply (xid=0x4): cookie=0x0, duration=31.96s, table=0, n_packets=2042759, n_bytes=93966914, idle_age=4, in_port=LOCAL actions=drop Round 5: NXST_FLOW reply (xid=0x4): cookie=0x0, duration=38.6s, table=0, n_packets=2040224, n_bytes=93850372, idle_age=8, in_port=LOCAL actions=drop Round 6: NXST_FLOW reply (xid=0x4): cookie=0x0, duration=35.661s, table=0, n_packets=2039595, n_bytes=93821418, idle_age=3, in_port=LOCAL actions=drop So there is a consistent benefit, but it is not very large. Seemingly the flow_extract() and flow_hash() represent only a small portion of the OVS flow setup CPU use. Jarno ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [tunnel 00/11] Flow based tunneling.
On 29 January 2013 00:12, Ben Pfaff wrote: > It looks like Ethan was able to fix the problems--he posted a new > version of patch 11 that says it fixes FreeBSD test failures. I didn't receive the new version of patch 11 (maybe Gmail decided it was a duplicate), but I grabbed it from the archive and applied the change. Thanks Ethan, it does fix the unit tests for me. Is there a reason to put the netdev_vport_(tunnel_)register in netdev-dummy.c for FreeBSD, instead of calling it always from lib/netdev.c? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [tunnel 00/11] Flow based tunneling.
> Is there a reason to put the netdev_vport_(tunnel_)register in > netdev-dummy.c for FreeBSD, instead of calling it always from > lib/netdev.c? Well, the BSD datapath (to my knowledge) doesn't support tunneling, so it doesn't make a lot of sense to register the provider as it couldn't possibly work. We do however need the providers in the unit tests where they're used as mocks. If we decide to add tunneling to BSD (perhaps in the dpif-netdev), we can begin registering it of course. Ethan ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/2] Add support for LISP into Open vSwitch
On Fri, Jan 25, 2013 at 2:13 PM, Kyle Mestery (kmestery) wrote: > On Jan 23, 2013, at 12:02 PM, Jesse Gross wrote: >> On Tue, Jan 22, 2013 at 10:36 AM, Kyle Mestery wrote: >>> The following two patches provide support for the LISP tunneling protocol >>> into >>> Open vSwitch. See the latest IETF draft for LISP here: >>> >>> http://tools.ietf.org/html/draft-ietf-lisp-24 >>> >>> Kyle Mestery (1): >>> Add support to the tunneling code for a "pre_tunnel" function. >>>This allows the tunneling code to perform operations on the >>>packet before the outer IP header is added. >>> >>> Lorand Jakab (1): >>> Add support for LISP tunneling >> >> Hi Kyle, >> >> I'm curious if you can share your long term plan for LISP. In >> particular there are three areas that I was wondering about: >> * L3 support. Obviously OVS is very Ethernet centric at this point, >> resulting in the need to play games with MAC addresses. >> * Additional LISP data plane support. LISP encodes more control >> information in the protocol itself compared to the existing OVS tunnel >> implementations, which basically only have the tunnel ID. It looks >> like this implementation generates nonces on transmit but otherwise >> doesn't try to handle the other pieces. >> * LISP control plane components. >> >> What do you guys see as the ideal end result? > > Hi Jesse: > > We see the following as the plan for LISP in OVS. I'd be interested to hear > feedback on this. > > Short term: > Make use of the vport-lisp.c which Lori has worked on. > > Medium to long term: > The control plane comes into play here. We see 2 options: > 1. No map server, everything done with static flows. > 2. A lightweight control plane for mappings lookup. This > would allow > vswitchd to query a map server (open source or > commercial) using > the LISP protocol (RFC 6830). > > Make OVS less ethernet specific. This work could be done in parallel > to the > above. I have not scoped this work out yet. > > Our high level proposal of how to get this done: > 1. Fix comments in Lori's existing patch with the hope of getting it into > OVS. This > does static flow programming and uses static MAC addresses. > 2. Update this to work with the NULL port support coming into the tunneling > code. > 3. Add the control plane work: > 1. Provisioning via an external controller and a light weight > EID-to-RLOC > mapping lookup in vswitchd. > 2. Hooks to allow for integration with an external map server. > 4. In parallel, work on making OVS less ethernet specific. > > Thoughts? This sounds like a reasonable plan to me. Does it make sense to mark this as experimental or otherwise subject to change? It seems likely that there will be user visible changes as new pieces are added (for example, the changes to make it less Ethernet specific will affect the flows) and we don't really want to have to maintain backwards compatibility in that regard. The other area that I'm somewhat concerned about is with upstreaming. Once we get OVS for GRE and VXLAN upstream (which Pravin is working on now), the delta between the out of tree module and in tree module will be very small. I'd like to keep on decreasing the differences but we may want to wait a little while for LISP until we get down further down your plan. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/2] Add support for LISP into Open vSwitch
On Jan 29, 2013, at 5:19 PM, Jesse Gross wrote: > On Fri, Jan 25, 2013 at 2:13 PM, Kyle Mestery (kmestery) > wrote: >> On Jan 23, 2013, at 12:02 PM, Jesse Gross wrote: >>> On Tue, Jan 22, 2013 at 10:36 AM, Kyle Mestery wrote: The following two patches provide support for the LISP tunneling protocol into Open vSwitch. See the latest IETF draft for LISP here: http://tools.ietf.org/html/draft-ietf-lisp-24 Kyle Mestery (1): Add support to the tunneling code for a "pre_tunnel" function. This allows the tunneling code to perform operations on the packet before the outer IP header is added. Lorand Jakab (1): Add support for LISP tunneling >>> >>> Hi Kyle, >>> >>> I'm curious if you can share your long term plan for LISP. In >>> particular there are three areas that I was wondering about: >>> * L3 support. Obviously OVS is very Ethernet centric at this point, >>> resulting in the need to play games with MAC addresses. >>> * Additional LISP data plane support. LISP encodes more control >>> information in the protocol itself compared to the existing OVS tunnel >>> implementations, which basically only have the tunnel ID. It looks >>> like this implementation generates nonces on transmit but otherwise >>> doesn't try to handle the other pieces. >>> * LISP control plane components. >>> >>> What do you guys see as the ideal end result? >> >> Hi Jesse: >> >> We see the following as the plan for LISP in OVS. I'd be interested to hear >> feedback on this. >> >> Short term: >>Make use of the vport-lisp.c which Lori has worked on. >> >> Medium to long term: >>The control plane comes into play here. We see 2 options: >>1. No map server, everything done with static flows. >>2. A lightweight control plane for mappings lookup. This >> would allow >> vswitchd to query a map server (open source or >> commercial) using >> the LISP protocol (RFC 6830). >> >>Make OVS less ethernet specific. This work could be done in parallel >> to the >>above. I have not scoped this work out yet. >> >> Our high level proposal of how to get this done: >> 1. Fix comments in Lori's existing patch with the hope of getting it into >> OVS. This >> does static flow programming and uses static MAC addresses. >> 2. Update this to work with the NULL port support coming into the tunneling >> code. >> 3. Add the control plane work: >>1. Provisioning via an external controller and a light weight >> EID-to-RLOC >> mapping lookup in vswitchd. >>2. Hooks to allow for integration with an external map server. >> 4. In parallel, work on making OVS less ethernet specific. >> >> Thoughts? > > This sounds like a reasonable plan to me. Does it make sense to mark > this as experimental or otherwise subject to change? It seems likely > that there will be user visible changes as new pieces are added (for > example, the changes to make it less Ethernet specific will affect the > flows) and we don't really want to have to maintain backwards > compatibility in that regard. > I think that seems fair. We can try our best to make things backwards compatible as we're doing the work, but the experimental nature will allow for some leeway if it's needed. > The other area that I'm somewhat concerned about is with upstreaming. > Once we get OVS for GRE and VXLAN upstream (which Pravin is working on > now), the delta between the out of tree module and in tree module will > be very small. I'd like to keep on decreasing the differences but we > may want to wait a little while for LISP until we get down further > down your plan. Is the goal to eventually not require the out of tree module? If that's the case, then perhaps we need to look at adding LISP support upstream into Linux in parallel to the plan above. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [coverity 01/12] meta-flow: Avoid null pointer dereference in mf_format_frag_string().
Acked-by: Ethan Jackson
On Thu, Jan 24, 2013 at 2:44 PM, Ben Pfaff wrote:
> The 'maskp' parameter to this function can be NULL, but the function
> always dereferenced it. This commit fixes the problem.
>
> This commit also fixes the order in which the value and mask were adjusted
> to correctly discard 1-bits outside of FLOW_NW_FRAG_MASK.
>
> Found by Coverity.
>
> Signed-off-by: Ben Pfaff
> ---
> lib/meta-flow.c |9 +++--
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/lib/meta-flow.c b/lib/meta-flow.c
> index 87887a8..8a92a5c 100644
> --- a/lib/meta-flow.c
> +++ b/lib/meta-flow.c
> @@ -2242,15 +2242,12 @@ mf_format_integer_string(const struct mf_field *mf,
> const uint8_t *valuep,
> }
>
> static void
> -mf_format_frag_string(const uint8_t *valuep, const uint8_t *maskp,
> - struct ds *s)
> +mf_format_frag_string(uint8_t value, uint8_t mask, struct ds *s)
> {
> const struct frag_handling *h;
> -uint8_t value = *valuep;
> -uint8_t mask = *maskp;
>
> -value &= mask;
> mask &= FLOW_NW_FRAG_MASK;
> +value &= mask;
>
> for (h = all_frags; h < &all_frags[ARRAY_SIZE(all_frags)]; h++) {
> if (value == h->value && mask == h->mask) {
> @@ -2309,7 +2306,7 @@ mf_format(const struct mf_field *mf,
> break;
>
> case MFS_FRAG:
> -mf_format_frag_string(&value->u8, &mask->u8, s);
> +mf_format_frag_string(value->u8, mask ? mask->u8 : UINT8_MAX, s);
> break;
>
> case MFS_TNL_FLAGS:
> --
> 1.7.2.5
>
> ___
> 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] [PATCH 0/2] Add support for LISP into Open vSwitch
On Tue, Jan 29, 2013 at 3:27 PM, Kyle Mestery (kmestery) wrote: > On Jan 29, 2013, at 5:19 PM, Jesse Gross wrote: >> The other area that I'm somewhat concerned about is with upstreaming. >> Once we get OVS for GRE and VXLAN upstream (which Pravin is working on >> now), the delta between the out of tree module and in tree module will >> be very small. I'd like to keep on decreasing the differences but we >> may want to wait a little while for LISP until we get down further >> down your plan. > > Is the goal to eventually not require the out of tree module? If that's the > case, then perhaps we need to look at adding LISP support upstream into > Linux in parallel to the plan above. Yes, I'd like to get to the point where the out of tree module is basically just a backported version of the upstream module and new things go into both roughly simultaneously. With the exception of tunneling related things, this should already be true. It would be great if you guys can think start thinking about the best way to integrate LISP with upstream since it is a little different from the other tunnel types. However, I don't want to predicate LISP in OVS on being upstream since the tunnel infrastructure needs to be upstreamed first. Once that happens it should be easier to add additional protocols. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] RFC: Pass more packet and flow key info to userspace.
On Tue, Jan 29, 2013 at 7:10 AM, Rajahalme, Jarno (NSN - FI/Espoo) wrote: > > On Jan 24, 2013, at 19:41 , ext Jesse Gross wrote: > >> On Thu, Jan 24, 2013 at 7:34 AM, Jarno Rajahalme >> wrote: >>> >>> On Jan 23, 2013, at 19:30 , ext Jesse Gross wrote: >>> On Tue, Jan 22, 2013 at 9:48 PM, Jarno Rajahalme wrote: > Add OVS_PACKET_ATTR_KEY_INFO to relieve userspace from re-computing > data already computed within the kernel datapath. In the typical > case of an upcall with perfect key fitness between kernel and > userspace this eliminates flow_extract() and flow_hash() calls in > handle_miss_upcalls(). > > Additional bookkeeping within the kernel datapath is minimal. > Kernel flow insertion also saves one flow key hash computation. > > Removed setting the packet's l7 pointer for ICMP packets, as this was > never used. > > Signed-off-by: Jarno Rajahalme > --- > > This likely requires some discussion, but it took a while for me to > understand why each packet miss upcall would require flow_extract() > right after the flow key has been obtained from odp attributes. Do you have any performance numbers to share? Since this is an optimization it's important to understand if the benefit is worth the extra complexity. >>> >>> Not yet, but would be happy to. Any hits towards for the best way of >>> obtaining >>> meaningful numbers for something like this? >> >> This is a flow setup optimization, so usually something like netperf >> TCP_CRR would be a good way to stress that. >> >> However, Ben mentioned to me that he had tried eliminating the >> flow_extract() call from userspace in the past and the results were >> disappointing. > > I made a simple test, where there is only one flow entry "in_port=LOCAL > actions=drop", and only the local port is configured. One process sends UDP > packets with different source/destination port combinations in a loop. OVS > then tries to cope with the load. During the test both processes run near > 100% CPU utilization in a virtual machine on a dual-core laptop. On each > round 1010 packets were generated: > > OFPST_PORT reply (xid=0x2): 1 ports > port LOCAL: rx pkts=1016, bytes=464600468, drop=0, errs=0, frame=0, > over=0, crc=0 >tx pkts=0, bytes=0, drop=0, errs=0, coll=0 > > With current master 19.35% of packets on average get processed by the flow: > > Round 1: > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=29.124s, table=0, n_packets=1959794, n_bytes=90150548, > idle_age=4, in_port=LOCAL actions=drop > > Round 2: > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=63.534s, table=0, n_packets=1932785, n_bytes=88908158, > idle_age=37, in_port=LOCAL actions=drop > > Round 3: > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=33.394s, table=0, n_packets=1972389, n_bytes=90729894, > idle_age=8, in_port=LOCAL actions=drop > > > With the proposed change 20.2% of packets on average get processed by the > flow: > > Round 4: > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=31.96s, table=0, n_packets=2042759, n_bytes=93966914, > idle_age=4, in_port=LOCAL actions=drop > > Round 5: > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=38.6s, table=0, n_packets=2040224, n_bytes=93850372, > idle_age=8, in_port=LOCAL actions=drop > > Round 6: > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=35.661s, table=0, n_packets=2039595, n_bytes=93821418, > idle_age=3, in_port=LOCAL actions=drop > > > So there is a consistent benefit, but it is not very large. Seemingly the > flow_extract() and flow_hash() represent only a small portion of the OVS flow > setup CPU use. Thanks for testing this out to get some concrete numbers. One thing that comes to mind is whether we actually use the layer pointers in the packet all that often. It seems to me that in cases where we are actually able to setup a kernel flow, userspace should be able to do all of its work by only looking at that flow. The other cases should be rare, like if userspace is directly consuming the packet or if the fit is not perfect. If that's the case, could we get a similar benefit without touching the userspace/kernel interface by only initializing the pointers on demand? ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 0/2] Add support for LISP into Open vSwitch
On Jan 29, 2013, at 6:47 PM, Jesse Gross wrote: > On Tue, Jan 29, 2013 at 3:27 PM, Kyle Mestery (kmestery) > wrote: >> On Jan 29, 2013, at 5:19 PM, Jesse Gross wrote: >>> The other area that I'm somewhat concerned about is with upstreaming. >>> Once we get OVS for GRE and VXLAN upstream (which Pravin is working on >>> now), the delta between the out of tree module and in tree module will >>> be very small. I'd like to keep on decreasing the differences but we >>> may want to wait a little while for LISP until we get down further >>> down your plan. >> >> Is the goal to eventually not require the out of tree module? If that's the >> case, then perhaps we need to look at adding LISP support upstream into >> Linux in parallel to the plan above. > > Yes, I'd like to get to the point where the out of tree module is > basically just a backported version of the upstream module and new > things go into both roughly simultaneously. With the exception of > tunneling related things, this should already be true. > Awesome, this is a very good goal to have. > It would be great if you guys can think start thinking about the best > way to integrate LISP with upstream since it is a little different > from the other tunnel types. However, I don't want to predicate LISP > in OVS on being upstream since the tunnel infrastructure needs to be > upstreamed first. Once that happens it should be easier to add > additional protocols. Yes, we'll start thinking about this as well. But in the meantime, we'll keep addressing comments you have on the existing patch, and work to integrate LISP in OVS per the plan we sent out. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
