Thank you for spending time thinking about this.
There is no loss of information in changing from a per-interface sampling model
to a per-bridge sampling model.
If there is a difference it's only on the configuration side, and since the OVS
sFlow config is already per-bridge, there is no confli
Hi Jesse,
On Tue, Apr 16, 2013 at 05:14:06PM +0900, Simon Horman wrote:
> Recirculation is a technique to allow a frame to re-enter
> frame processing. This is intended to be used after actions
> have been applied to the frame with modify the frame in
> some way that makes it possible for richer p
OK, thanks for the explanation. I guess the part that I'm not entirely
sure about is what is the tradeoff in modeling this as being
per-bridge rather than per-port? It seems like like in the case of
per-bridge sampling you are still including the ifIndex with the
sample metadata so you don't lose a
On Thu, Apr 25, 2013 at 2:37 PM, Justin Pettit wrote:
>
> On Apr 25, 2013, at 10:33 AM, Ben Pfaff wrote:
>
> > On Mon, Apr 08, 2013 at 10:51:44AM -0700, Justin Pettit wrote:
> >> @@ -2274,7 +2274,8 @@ bridge_run(void)
> >> struct bridge *br, *next_br;
> >>
> >> VLOG_ERR_R
On Apr 25, 2013, at 11:23 AM, Ben Pfaff wrote:
> I'd really like to get multiple reviews on this. Justin, are you
> willing to spend some time looking over v2?
Happy to do it. I'll get it done today.
--Justin
___
dev mailing list
dev@openvswitch.o
On Apr 25, 2013, at 10:33 AM, Ben Pfaff wrote:
> On Mon, Apr 08, 2013 at 10:51:44AM -0700, Justin Pettit wrote:
>> @@ -2274,7 +2274,8 @@ bridge_run(void)
>> struct bridge *br, *next_br;
>>
>> VLOG_ERR_RL(&rl, "another ovs-vswitchd process is running, "
>> -
On Thu, Apr 25, 2013 at 5:28 AM, Thomas Graf wrote:
> Repost of RHEL6.4 datapath updates.
>
> Thomas Graf (2):
> datapath: Use openvswitch_handle_frame hook in >=RHEL6.4 to live side
> by side with bridging
> datapath: Account for RHEL6.4 backports in compat layer
Both applied, thanks for
I forgot to note in this version that this applies to branch-1.4.
On Thu, Apr 25, 2013 at 11:23:00AM -0700, Ben Pfaff wrote:
> In the case where execute_controller_action() returned true to
> handle_flow_miss(), indicating that the packet had been sent to the
> controller, nothing ever freed the p
It's not "normal". It indicates a bug, although if they are only seen
occasionally it is not a big deal. What commit is the original XS 6.1
OVS based on?
On Wed, Apr 24, 2013 at 09:48:32PM +0100, Zoltan Kiss wrote:
> Hi,
>
> Thanks, I've made my comments on that thread. Another related
> questi
Thanks for the corrections. I sent out a v2 with those fixes.
I'd really like to get multiple reviews on this. Justin, are you
willing to spend some time looking over v2?
Thanks,
Ben.
On Wed, Apr 24, 2013 at 09:44:20PM +0100, Zoltan Kiss wrote:
> I've reviewed and tested this. In the patch de
In the case where execute_controller_action() returned true to
handle_flow_miss(), indicating that the packet had been sent to the
controller, nothing ever freed the packet, causing a memory leak.
One plausible solution seemed to be to turn over ownership of the packet to
execute_controller_action
On Mon, Apr 08, 2013 at 10:51:44AM -0700, Justin Pettit wrote:
> @@ -2274,7 +2274,8 @@ bridge_run(void)
> struct bridge *br, *next_br;
>
> VLOG_ERR_RL(&rl, "another ovs-vswitchd process is running, "
> -"disabling this process until it goes away")
Looks good to me.
On Mon, Apr 8, 2013 at 10:51 AM, Justin Pettit wrote:
> Normally, the daemon code will detect when multiple instances are run
> and print the conflicting PID. However, if ovs-vswitchd is not run in
> daemon mode or the pidfile is removed, a database lock is checked. The
> me
Normally, the daemon code will detect when multiple instances are run
and print the conflicting PID. However, if ovs-vswitchd is not run in
daemon mode or the pidfile is removed, a database lock is checked. The
message it prints wasn't specific enough about which process was backing
off due to no
iphone5 3999 ipad mini 1999 超多正品包邮 五一必备！
华强北商城 http://e.richedm.com/a/tBReML3B8enbWB8yLoiAASrZTei/ok6
如信箱不能正常阅读，请点击这里>> : http://e.richedm.com/a/tBReML3B8enbWB8yLoiAASrZTei/ok1
首页 : http://e.richedm.com/a/tBReML3B8enbWB8yLoiAASrZTei/ok5
3点惠 : http://e.richedm.com/a/tBReML3B8enbWB8yLoiAASrZTei
Allow datapath to recognize and extract MPLS labels into flow keys
and execute actions which push, pop, and set labels on packets.
Based heavily on work by Leo Alterman and Ravi K.
Cc: Ravi K
Cc: Leo Alterman
Reviewed-by: Isaku Yamahata
Signed-off-by: Simon Horman
---
This is the remaining
I find the reason why ovs commits so many transactions.
In bridge_run, ovs-vswitchd would refresh interface statistic if necessary. If
the number of ports is big enough such as 500, it will take a long time to
check every port's statistic. If statistic changes, ovs- vswitchd will send
messages
Explicitly check the availability of several kernel API functions
instead of relying on the kernel version to account for Red Hat
Enterprise Linux backports.
Signed-off-by: Thomas Graf
---
V2:
- Move can_checksum_protocol() back into #ifdef
acinclude.m4| 7 +
Due to the missing register rx_handler API in the kernel RHEL6 is
based on, the datapath currently falls back to using the bridging
hook with the consequence that bridging and OVS cannot be used in
parallel on any RHEL6 release.
For this purpose, >=RHEL6.4 releases provide a special rx frame hook
Repost of RHEL6.4 datapath updates.
Thomas Graf (2):
datapath: Use openvswitch_handle_frame hook in >=RHEL6.4 to live side
by side with bridging
datapath: Account for RHEL6.4 backports in compat layer
acinclude.m4| 10 +++
datapath/linux/compat/inc
On Thu, Apr 25, 2013 at 11:28:18AM +, Rajahalme, Jarno (NSN - FI/Espoo)
wrote:
>
> On Apr 25, 2013, at 14:02 , ext Simon Horman wrote:
> >
> > Yes, stack_len is supposed to advance by one for each iteration of the loop.
>
> Better make it by four instead ;-)
Yes :-)
___
On Apr 25, 2013, at 14:02 , ext Simon Horman wrote:
>
> Yes, stack_len is supposed to advance by one for each iteration of the loop.
Better make it by four instead ;-)
Jarno
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/lis
On Thu, Apr 25, 2013 at 10:02:49AM +, Rajahalme, Jarno (NSN - FI/Espoo)
wrote:
>
> On Apr 25, 2013, at 10:58 , ext Simon Horman wrote:
>
> > @@ -648,6 +650,7 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port,
> > struct sw_flow_key *key,
> > return -ENOMEM;
> >
> > s
On Apr 25, 2013, at 10:58 , ext Simon Horman wrote:
> @@ -648,6 +650,7 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port,
> struct sw_flow_key *key,
> return -ENOMEM;
>
> skb_reset_network_header(skb);
> + skb_reset_mac_len(skb);
> __skb_push(skb, skb->data
On Thu, Apr 25, 2013 at 04:36:44PM +0900, Simon Horman wrote:
> On Tue, Apr 23, 2013 at 02:00:19PM -0700, Joseph Gasparakis wrote:
> >
> >
> > On Mon, 22 Apr 2013, Simon Horman wrote:
> >
> > > "net: Add support for hardware-offloaded encapsulation" introduced
> > > the encapsulation field of st
Allow datapath to recognize and extract MPLS labels into flow keys
and execute actions which push, pop, and set labels on packets.
Based heavily on work by Leo Alterman and Ravi K.
Cc: Ravi K
Cc: Leo Alterman
Reviewed-by: Isaku Yamahata
Signed-off-by: Simon Horman
---
This is the remaining
On Tue, Apr 23, 2013 at 02:00:19PM -0700, Joseph Gasparakis wrote:
>
>
> On Mon, 22 Apr 2013, Simon Horman wrote:
>
> > "net: Add support for hardware-offloaded encapsulation" introduced
> > the encapsulation field of struct skb, which when set provides hints
> > that GSO should handle an skb th
On Tue, Apr 23, 2013 at 04:43:58PM -0700, Jesse Gross wrote:
> On Mon, Apr 22, 2013 at 7:19 PM, Simon Horman wrote:
> > In the case where a non-MPLS GSO skb becomes an MPLS GSO skb, via
> > Open vSwitch's push MPLS action it is desirable to provide segmentation
> > in software. In this case the or
28 matches
Mail list logo
