Please keep this on the list.
I'm somewhat familiar with Cavium's platforms. One option would be to bring up
the cores in Linux, and I think you could run the kernel module essentially
unchanged. Another option, which would be a lot more work but would almost
certainly be faster, is to port d
What operating system and platform are you porting it to? The ofproto provider
pushes flows that have wildcards, and are very similar to OpenFlow flows. The
dpif provider only pushes exact-match flows. If you have access to something
like a TCAM that supports priorities and wildcards, then im
i have some question about PORTING file. there is a graph in this file as
follow:
[image: 内嵌图片 1]
now i am willing to port the source code to a network processor ,which is
MIPS arch. my goal is implement the kernel module in the platform.but i
still cannot figure out a clear procedure about it. whi
On Mar 7, 2013, at 11:11 AM, Ben Pfaff wrote:
> On Wed, Mar 06, 2013 at 05:16:24PM -0800, Justin Pettit wrote:
>
> But here I'd expect the arguments on the second and third line to be
> indented just past the opening parenthesis:
>> +compose_slow_path(ofproto, &subfacet->facet->flow,
On Mar 7, 2013, at 11:18 AM, Ben Pfaff wrote:
> On Wed, Mar 06, 2013 at 06:16:34PM -0800, Justin Pettit wrote:
>> Signed-off-by: Justin Pettit
>
> Looks good, thanks.
Thanks. I pushed these to master.
--Justin
___
dev mailing list
dev@openvswitc
Thanks, pushed to master and branch-1.10.
On Thu, Mar 07, 2013 at 05:09:34PM -0800, Ethan Jackson wrote:
> Acked-by: Ethan Jackson
>
>
>
> On Thu, Mar 7, 2013 at 5:07 PM, Ben Pfaff wrote:
>
> > backtrace() is really useful, but it is not signal safe everywhere. We
> > need to reassess wheth
Acked-by: Ethan Jackson
On Thu, Mar 7, 2013 at 5:07 PM, Ben Pfaff wrote:
> backtrace() is really useful, but it is not signal safe everywhere. We
> need to reassess whether it is reasonable to use it anywhere, but
> immediately we need to disable it on x86-64 (with glibc) because it is
> cau
backtrace() is really useful, but it is not signal safe everywhere. We
need to reassess whether it is reasonable to use it anywhere, but
immediately we need to disable it on x86-64 (with glibc) because it is
causing segfaults in testing.
Bug #15497.
Reported-by: Ram Jothikumar
Signed-off-by: Ben
On Thu, Mar 7, 2013 at 7:41 AM, Rajahalme, Jarno (NSN - FI/Espoo)
wrote:
> I recall someone mentioning on this list that the only planned use for
> skb_mark is for ipsec tunneling. At least currently this seems to be the
> case, as the only place where the skb_mark is set to a potentially non-ze
On Wed, Mar 06, 2013 at 06:16:34PM -0800, Justin Pettit wrote:
> Signed-off-by: Justin Pettit
Looks good, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Mar 06, 2013 at 06:16:33PM -0800, Justin Pettit wrote:
> Signed-off-by: Justin Pettit
Looks good, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Thu, Mar 07, 2013 at 06:13:06PM +0100, Simon Horman wrote:
> On Wed, Mar 06, 2013 at 02:57:59PM -0800, Ben Pfaff wrote:
> > RFC 3443 says that an outgoing MPLS TTL of zero is invalid, so we must send
> > packets that have such a TTL post-decrement to the controller rather than
> > allowing them
On Thu, Mar 07, 2013 at 04:12:22AM +0100, Simon Horman wrote:
> Perhaps Ben has some ideas, but it seems to me that the
> way that execute_* and compose_* interact needs to be changed
> around in order to preserve the order of actions.
This seems likely to be necessary.
___
On Wed, Mar 06, 2013 at 05:16:24PM -0800, Justin Pettit wrote:
> The command "ovs-appctl dpif/dump-flows" would print slow-path actions
> as "drop", which could be confusing to users. This is different from
> "ovs-dpctl dump-flows", which prints a descriptive reason. This commit
> replaces "drop"
On Thu, Mar 7, 2013 at 7:41 AM, Rajahalme, Jarno (NSN - FI/Espoo)
wrote:
> I recall someone mentioning on this list that the only planned use for
> skb_mark is for ipsec tunneling. At least currently this seems to be the
> case, as the only place where the skb_mark is set to a potentially non-ze
On Wed, Mar 06, 2013 at 02:57:59PM -0800, Ben Pfaff wrote:
> RFC 3443 says that an outgoing MPLS TTL of zero is invalid, so we must send
> packets that have such a TTL post-decrement to the controller rather than
> allowing them to continue through the OpenFlow tables.
>
> Here is the text from RF
Ok, I'm cross-posting to OpenVSwitch devel mailing and libvirt-users
mailing so we all are in the same tune :-)
If you didn't read the original mail that I sent, it is about an issue
that I'm having on Debian that when I reboot or shutdown the host
system, OVS is stopped before the KVMs are taking
On Wed, Mar 06, 2013 at 08:55:42AM -0800, Ben Pfaff wrote:
> On Wed, Mar 06, 2013 at 04:08:12PM +0900, Simon Horman wrote:
> > On Wed, Mar 06, 2013 at 10:43:45AM +0900, Simon Horman wrote:
> > > On Tue, Mar 05, 2013 at 10:23:10AM -0800, Ben Pfaff wrote:
> > > > On Thu, Feb 28, 2013 at 06:15:08PM +0
On Wed, Mar 06, 2013 at 09:12:53AM -0800, Jesse Gross wrote:
> On Tue, Mar 5, 2013 at 10:03 PM, Simon Horman wrote:
> > On Tue, Mar 05, 2013 at 11:35:41AM -0800, Jesse Gross wrote:
> >> On Tue, Mar 5, 2013 at 10:23 AM, Ben Pfaff wrote:
> >> > On Thu, Feb 28, 2013 at 06:15:09PM +0900, Simon Horman
I recall someone mentioning on this list that the only planned use for skb_mark
is for ipsec tunneling. At least currently this seems to be the case, as the
only place where the skb_mark is set to a potentially non-zero value in
userspace is in tnl_port_send(). The kernel datapath may also provi
20 matches
Mail list logo
