On Thu, Feb 16, 2012 at 04:53:35PM -0800, Ben Pfaff wrote:
> On Thu, Feb 16, 2012 at 04:32:57PM -0800, Jesse Gross wrote:
> > On Thu, Feb 16, 2012 at 10:36 AM, Ben Pfaff wrote:
> > > OVS needs to inspect the headers in the kernel source directory at build
> > > time. Debian keeps moving the sourc
On Thu, Feb 16, 2012 at 4:39 PM, Jesse Gross wrote:
> On Thu, Feb 16, 2012 at 4:16 PM, Pravin B Shelar wrote:
>> Use hash table to store ports of datapath. Allow 64K ports per switch.
>>
>> Signed-off-by: Pravin B Shelar
>>
>> Bug #2462
>
> Looks good, thank you.
> Acked-by: Jesse Gross
>
Thank
On Thu, Feb 16, 2012 at 10:42:27AM -0800, Ben Pfaff wrote:
> On Thu, Feb 16, 2012 at 05:45:24PM +0800, Thomas Goirand wrote:
> > checking for Linux build directory... /usr/src/linux-headers-3.1.0-1-686-pae
> > checking for Linux source directory... configure: error: cannot find source
> > director
On Thu, Feb 16, 2012 at 04:32:57PM -0800, Jesse Gross wrote:
> On Thu, Feb 16, 2012 at 10:36 AM, Ben Pfaff wrote:
> > OVS needs to inspect the headers in the kernel source directory at build
> > time. Debian keeps moving the source directory relative to the build
> > directory and doesn't provide
On Thu, Feb 16, 2012 at 4:16 PM, Pravin B Shelar wrote:
> Use hash table to store ports of datapath. Allow 64K ports per switch.
>
> Signed-off-by: Pravin B Shelar
>
> Bug #2462
Looks good, thank you.
Acked-by: Jesse Gross
Can you provide a port to the upstream tree for this (and I think we
st
On Thu, Feb 16, 2012 at 02:10:02PM -0800, Ethan Jackson wrote:
> > Please argue out the situation with yourself and get back to me when
> > you've come to a conclusion.
>
> After an intense bout of self directed parliamentary wrangling
> (back-room deals, filibusters, ear marks, late night socrati
On Thu, Feb 16, 2012 at 10:36 AM, Ben Pfaff wrote:
> OVS needs to inspect the headers in the kernel source directory at build
> time. Debian keeps moving the source directory relative to the build
> directory and doesn't provide an obvious way to find the source directory,
> so in the past we've
Fixed according to comments from Jesse.
v4-v5:
- Coding style fixes.
v3-v4:
- Removed vport count.
- Optimized dpif_linux_port_add() for compatibility case.
v2-v3:
- Limit max number of ports to 64K.
- Limit actions-len to 16kb.
- Coding style fixes.
On Thu, Feb 16, 2012 at 3:41 PM, Pravin Shelar wrote:
> On Thu, Feb 16, 2012 at 3:26 PM, Jesse Gross wrote:
>> On Thu, Feb 16, 2012 at 1:27 PM, Pravin B Shelar wrote:
>>> @@ -409,9 +373,14 @@ dpif_linux_port_add(struct dpif *dpif_, struct netdev
>>> *netdev,
>>> *port_nop = reply.po
On Thu, Feb 16, 2012 at 3:26 PM, Jesse Gross wrote:
> On Thu, Feb 16, 2012 at 1:27 PM, Pravin B Shelar wrote:
>> diff --git a/datapath/datapath.c b/datapath/datapath.c
>> index 220c7dd..9d3c997 100644
>> --- a/datapath/datapath.c
>> +++ b/datapath/datapath.c
>> +static struct hlist_head *vport_ha
On Thu, Feb 16, 2012 at 1:27 PM, Pravin B Shelar wrote:
> diff --git a/datapath/datapath.c b/datapath/datapath.c
> index 220c7dd..9d3c997 100644
> --- a/datapath/datapath.c
> +++ b/datapath/datapath.c
> +static struct hlist_head *vport_hash_bucket(const struct datapath *dp, u16
> port_no)
Some o
> Please argue out the situation with yourself and get back to me when
> you've come to a conclusion.
After an intense bout of self directed parliamentary wrangling
(back-room deals, filibusters, ear marks, late night socratic
dialectics) I've come to the following conclusion:
HFSC drops packets
Fixed according to comments from Jesse.
v3-v4:
- Removed vport count.
- Optimized dpif_linux_port_add() for compatibility case.
v2-v3:
- Limit max number of ports to 64K.
- Limit actions-len to 16kb.
- Coding style fixes.
v1-v2:
- Use hash table.
On Wed, Feb 15, 2012 at 03:30:49PM +0900, Simon Horman wrote:
> [handle_packet_out() in the patch.]
> ofpacts seems to be use uninitialised.
> Is it necessary to some how initialise ofpacts from
> po.actions and po.n_actions?
Oops. We can just use po.ofpacts:
diff --git a/ofproto/ofproto.c b/ofp
Thanks. I pushed this as-is.
On Tue, Feb 14, 2012 at 05:28:09PM -0800, Ethan Jackson wrote:
> Looks good.
>
> Ethan
>
> On Tue, Feb 14, 2012 at 15:21, Ben Pfaff wrote:
> > Not only have we never implemented this, no one has ever asked for it to
> > the best of my knowledge.
> >
> > This increm
On Thu, Feb 16, 2012 at 10:36:34AM -0800, Ben Pfaff wrote:
> OVS needs to inspect the headers in the kernel source directory at build
> time. Debian keeps moving the source directory relative to the build
> directory and doesn't provide an obvious way to find the source directory,
> so in the past
On Thu, Feb 16, 2012 at 05:45:24PM +0800, Thomas Goirand wrote:
> checking for Linux build directory... /usr/src/linux-headers-3.1.0-1-686-pae
> checking for Linux source directory... configure: error: cannot find source
> directory (please use --with-linux-source)
It seems we need a new way to f
OVS needs to inspect the headers in the kernel source directory at build
time. Debian keeps moving the source directory relative to the build
directory and doesn't provide an obvious way to find the source directory,
so in the past we've used some name-based heuristics to essentially guess
where i
On Thu, Feb 16, 2012 at 12:10:29AM +0100, ravi.ke...@telekom.com wrote:
> I have installed sparse and am running make C=1, didn't see the
> warning. I know there is a problem in the code just wanted to check
> if it's the correct way?
That's the right way to get the warnings, yes. If you installe
If the behavior that you're looking for is actually the same as vxlan
then you might want to help out the guys who are planning on working
on it. There's some discussion here:
http://openvswitch.org/pipermail/dev/2012-February/014685.html
On Thu, Feb 16, 2012 at 7:10 AM, Dan Mihai Dumitriu wrote
Understood, thanks!
On Thursday, February 16, 2012, Justin Pettit wrote:
> On Feb 15, 2012, at 8:37 PM, Dan Mihai Dumitriu wrote:
>
>> That is true, such usage would definitely not be standard compliant.
>>
>> Incidentally, are OVS CAPWAP tunnels actually being used to connect to
non-OVS endpoin
Hi,
I've reopened this bug, because this didn't fix it. Attached is the
make.log.
Thomas
DKMS make.log for openvswitch-1.4.0 for kernel 3.1.0-1-686-pae (i686)
Thu Feb 16 09:30:27 UTC 2012
checking build number... none
checking for a BSD-compatible install... /usr/bin/install -c
checking whether b
Processing commands for cont...@bugs.debian.org:
> reopen 659685
Bug #659685 {Done: Simon Horman } [openvswitch-datapath-dkms]
fails to build the kernel module
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to use 'found' to remove fixed versions.
>
End of m
We have a comprehensive data file containing businesses in the USA.
-> 4 Million total records, all with emails
-> The list has records for over 9,000 business categories
-> Everything arranged by SIC code
Get a sample and more details today, simply send a quick email to
greg.park...@gmx.us or c
24 matches
Mail list logo
