er handle the issue.
Neil Ren
International Department/Manager
China IPR/China Intellectual Property Office
Add:3/F,1st Building ZongFu Street No.47,Jinjiang District, ChengDu, China.
Tel: (+86) 28 8777 5008|Fax: (+86) 28 6246 5008|Web: http://www.cn-nic.asia
P Please consider the environment befo
7;m hoping this can go in. These LACP and port-name extensions are useful
as they stand. No need to wait for the tunnel stuff to settle. Let me
know if you need me to do anything else.
Regards,
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Tue, Jul 15, 2014 at 4:31 PM, Neil M
/host-sflow/blob/master/src/Linux/hsflowd.c#L373
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Thu, Jun 16, 2016 at 4:16 AM, Lal, PrzemyslawX wrote:
> Hi Mark,
>
> RFC 2863 standard describes in "Interface Numbering" chapter (
> https://tools.ietf.org/html/rf
you want to drive with this
feed?
Neil
On Tue, Jul 5, 2016 at 5:26 AM, Robert Wojciechowicz
wrote:
> The OVS PMD threads utilization has been identified
> as important metric when managing large deployments.
> This patch exposes via sFlow PMD utilization metrics,
> which are also a
This patch avoids a segfault that was found and documented here:
http://openvswitch.org/pipermail/discuss/2016-August/022513.html
I raised a pull-request on github.
Signed-off-by: Neil McKee
---
ofproto/ofproto-dpif-sflow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
0%. For a thorough analysis
of this problem, see Rick Jones' paper:
"High Frequency sFlow v5 Counter Sampling"
ftp://ftp.netperf.org/papers/high_freq_sflow/hf_sflow_counters.pdf
So this patch makes it possible to obtain usable results even
when high-frequency polling is configured.
This one perturbs the output ordering just enough to fail two of the
sflow unit tests. Sorry I didn't notice that before. I'll post
another patch for that.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Sep 2, 2016 at 11:47 AM, Ben Pfaff wrote:
> On Mon, Aug 2
([CHECK_SFLOW_SAMPLING_PACKET],
dnl sleep long enough to get more than one counter sample
dnl from each datasource so we can check sequence numbers
- ovs-appctl time/warp 3000 100
+ ovs-appctl time/warp 2000 100
OVS_VSWITCHD_STOP
OVS_APP_EXIT_AND_WAIT([test-sflow])
--
Neil McKee
InMon Corp
pproach is accepted then I can follow up with further enhancements
to report on QinQ, NAT, 64-bit tunnel keys, and to improve the
monitoring of Geneve and STT. That should all be pretty straightforward
now. No further changes to datapath required.
Neil
--
Neil McKee
InMon
Sure, I'll try to get to that tonight.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Jul 17, 2015 at 4:31 PM, Ben Pfaff wrote:
> On Thu, Jun 11, 2015 at 09:43:59AM -0700, Neil McKee wrote:
> > Packets are still sampled at ingress only, so the egress
> >
in future patches that make only incremental
changes.
Signed-off-by: Neil McKee
---
lib/dpif-netlink.c| 2 +
lib/dpif.h| 1 +
lib/odp-util.c| 25 +-
lib/odp-util.h| 1 +
ofproto/ofproto-dpif-sflo
Wow. That's great. Thanks. I will look at what else we should add to the
sFlow export. (e.g. QinQ, NAT, ...). Should be straighforward now that we
have the actions for each sample.
Neil
On Tuesday, July 21, 2015, Ben Pfaff wrote:
> On Fri, Jul 17, 2015 at 09:37:02PM -0700, Ne
Acked-by: Neil Horman
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
OK, I forked openvwitch/ovs on github to create this repo:
https://github.com/sflow/ovs
and then pushed the patch in there (with "Signed-off-by" in the commit
comment).
https://github.com/sflow/ovs/commit/7aff910325fa3a4a11d363f09e06f83c64209485
Should I submit a pull-request?
Reg
I'll
devote more time and try to fill out the sFlow feature set. That will make
it easier to offer desirable things like per-tenant sFlow feeds. Let me
know if there is a deadline.
Neil
___
dev mailing list
dev@openvswitch.org
http://openv
OK, I'll reply again when I have extended this forked-repo to export the
standard sFlow-LAG structure.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Jul 7, 2014 at 8:55 AM, Ben Pfaff wrote:
> I took a look at the patch. It's not necessary to submit a
&
t;bundle" and it's pointer to
"lacp" are not going to be moving around underfoot.
Regards,
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Wed, Jul 9, 2014 at 3:08 PM, Neil McKee wrote:
>
> OK, I'll reply again when I have extended this forked-repo
rom the
kernel? Is that worth pursuing?
5) something else?
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
option (1), but it really does seem to have all
the problems that Jesse and Ben anticipated in 2011.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Wed, Apr 1, 2015 at 10:14 PM, Neil McKee wrote:
> I've been looking at filling in the sFlow structures to report
On Fri, Apr 3, 2015 at 3:14 PM, Jesse Gross wrote:
> On Wed, Apr 1, 2015 at 10:14 PM, Neil McKee wrote:
> > I've been looking at filling in the sFlow structures to report on tunnel
> > encap and other transformations. sFlow sampling is best done on ingress
> > only,
On Fri, Apr 3, 2015 at 4:21 PM, Joe Stringer wrote:
> Missed this the first time around for some reason. Minor comments inline.
>
> On 1 April 2015 at 22:14, Neil McKee wrote:
> > 1) We can use the concurrent hash-map of flows that the revalidator
> > threads are sharing.
actions at his fingertips for any packet that might be
sampled.
Thoughts?
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Apr 6, 2015 at 3:23 PM, Jesse Gross wrote:
> On Sat, Apr 4, 2015 at 8:45 AM, Neil McKee wrote:
> >
> > On Fri, Apr 3, 2015 at 3:
d that the (optional) kernel datapath changes will need to
be submitted as a kernel
patch on netdev. I can try that, but I'm guessing I won't get much
attention there without
input from someone they have heard of. How does it work? Should I
just post the patch to
get the ball rol
ing of set(tunnel()),
tnl_push() and push_mpls() actions.
Signed-off-by: Neil McKee
---
datapath/actions.c| 14 +-
datapath/datapath.c | 18 ++
datapath/datapath.h | 2 +
lib/dpif-netlink.c| 2 +
lib/dpif.h| 1 +
ofproto/of
everywhere so a missing field
can typically be seen at ingress to the next switch in the path.
This patch also adds unit tests to check the sFlow encoding of set(tunnel()),
tnl_push() and push_mpls() actions.
Signed-off-by: Neil McKee
---
datapath/actions.c| 14 +-
datapath/
not dependent on the kernel part.
Neil
On Fri, May 15, 2015 at 5:53 PM, Jesse Gross wrote:
> On Fri, May 15, 2015 at 3:04 PM, Neil McKee wrote:
>> I understand that the (optional) kernel datapath changes will need to
>> be submitted as a kernel
>> patch on netdev. I c
datapath actions that may be added in the future.
Adding path information enhances visibility into complex virtual networks.
Signed-off-by: Neil McKee
---
datapath/actions.c | 14 +-
datapath/datapath.c | 18 ++
datapath/datapath.h | 2 ++
3 files changed, 29 insertions
everywhere so a missing field
can typically be seen at ingress to the next switch in the path.
This patch also adds unit tests to check the sFlow encoding of set(tunnel()),
tnl_push() and push_mpls() actions.
Signed-off-by: Neil McKee
---
lib/dpif-netlink.c| 2 +
Yes. I'll do that. They have changed slightly now that the option to
request the actions is an attribute of the "userspace" action.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Tue, May 26, 2015 at 7:17 PM, Ben Pfaff wrote:
> On Fri, May 15, 2015 at 05:53
in future patches that make only incremental
changes.
Signed-off-by: Neil McKee
---
lib/dpif-netlink.c| 2 +
lib/dpif.h| 1 +
lib/odp-util.c| 25 +-
lib/odp-util.h| 1 +
ofproto/ofproto-dpif-sflo
: Neil McKee
---
datapath/actions.c| 23 +++
datapath/datapath.c | 18 --
datapath/datapath.h | 2 ++
datapath/linux/compat/include/linux/openvswitch.h | 5 -
4 files
On Mon, Dec 30, 2013 at 4:08 PM, Ben Pfaff wrote:
> On Fri, Dec 20, 2013 at 03:45:37PM -0800, Neil McKee wrote:
> > Sorry. Grappling with a new email client. Here it as an attachment, if
> > that's OK. Let me know if I need to rebase again.
>
> This patch provokes
Thanks for the detailed explanation. You should teach a class :)I'll
rework the patch.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Thu, Jan 9, 2014 at 11:43 AM, Ben Pfaff wrote:
> On Fri, Jan 03, 2014 at 09:39:00PM -0800, Neil McKee wrote:
> > On Mon, Dec
Sorry for the delay. Looks good. And thanks for pointing this out.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Tue, Jan 7, 2014 at 1:28 AM, Francesco Fusco wrote:
> Neil,
> did you have a chance to have a look at the patch?
>
> Best,
> Francesco
>
>
>
Finally getting back to this. Can we do it one piece at a time? For
example, attached is a patch that just adds counters to the LACP
module and a call to retrieve them.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Mon, Jan 13, 2014 at 8:29 AM, Neil McKee wrote:
> Thanks
. I hope that's going to be OK?
(And let me know if you would prefer this to be in a new email-thread.)
Regards,
Neil
---
[PATCH] Prepare ground for extensions to sFlow export.
Standard LACP counters are added to the LACP
module, and the sFlow library and test modules are extended
to suppor
sulation:1;
> + __u8missed_flow:1;
> /* 6/8 bit hole (depending on ndisc_nodetype presence) */
> kmemcheck_bitfield_end(flags2);
Presumably you need to update the "6/8 bit hole" comment here.
Regards,
Neil
_
t; + To compile this code as a module, choose M here: the
> + module will be called pktgen.
> +
"pktgen" cut'n'paste typo.
Neil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_swdev_register(dev);
> + rtnl_unlock();
> + return err;
> +}
> +EXPORT_SYMBOL(swdev_register);
2. Why grab and release the rtnl lock, given that there appears to be nothing
rtnl-related in between?
Regards,
Neil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
efficient and scalable alternative to polling via ovs-dpctl(1).
It's safe to assume that the patch below was mangled by my email setup, so
I posted a github pull-request here:
https://github.com/openvswitch/ovs/pull/31
Signed-off-by: Neil McKee
---
lib/sflow.h | 34 ++-
to see if there was a way to set a bit in
the skbuff that would survive and come back in a sample, but I'm not sure
how to go about doing that.
Or maybe there is another way?
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev m
ies to store l2 lookups with a least recently used
replacement policy
or
ip route offload enable dev sw0 cachesize 1000 policy maxuse
to reserve 1000 entries to store l3 lookups with a replacement policy that only
replaces routes who's hit count is larger than the least used in the cache
By
ulated traffic.
So this way you get the full picture. It's just that your sFlow collector
sometimes has to decode deeper into the packet to pull out the inner
addresses etc.
I hope this is clear.
Neil
--
Neil McKee
InMon Corp.
http://www.inmon.com
On Fri, Nov 6, 2015 at 5:40 A
guess this behavior
could be off by default and turned on just for this test.
I have only tested this on a Fedora 17 OS.
Signed-off-by: Neil McKee
---
lib/netdev-dummy.c| 15 +-
tests/automake.mk | 4 +
tests/ofproto-dpif.at | 54 +
tests/test-sflow.c| 539
On Mar 29, 2013, at 4:16 PM, Ben Pfaff wrote:
> On Wed, Mar 27, 2013 at 11:02:21PM -0700, Neil Mckee wrote:
>> This patch adds an sFlow test to the test suite (in branch 1.10). To make
>> that work properly I added netdev_dummy_get_ifindex() so that a dummy netdev
>&g
That answers all my questions. I was indeed in the 1.10 branch.
(And please reformat the C code. It shares snippets with the sFlow decoder in
Ganglia, but not enough to matter.)
Neil
On Mar 31, 2013, at 8:31 PM, Ben Pfaff wrote:
> I'll do an update to the patch tomorrow but h
ecific language governing permissions and
* limitations under the License.
*/
You don't need me sign off again, right? You can submit the revised patch
yourself?
Neil
On Mar 31, 2013, at 9:48 PM, Neil McKee wrote:
> That answers all my questions. I was indeed in the 1.10 branch.
>
&g
You probably noticed this, but choose-port.pl is sometimes being used to
return a free TCP port which is promptly used for UDP. Perhaps
choose-port.pl should take an argument?
Neil
On Apr 3, 2013, at 12:02 PM, Ben Pfaff wrote:
> An occasionally occurring problem with "ma
port X at the same
time as someone else has opened TCP port X.
Or did I miss something?
Neil
On Apr 3, 2013, at 2:23 PM, Ben Pfaff wrote:
> I didn't notice that, but this commit actually removes choose-port.pl
> entirely so it presumably fixes that problem?
>
> I'll add
Yes, that makes sense. Thanks.
Neil
On Apr 3, 2013, at 6:47 PM, Ben Pfaff wrote:
> On Wed, Apr 03, 2013 at 05:01:40PM -0700, Neil Mckee wrote:
>> "parse-listening-port" seems to return the port that the server was
>> told to listen on(?)
>
> Yes, it retu
sFlow counter samples remain unchanged, reporting only on interfaces
that have valid ifIndex numbers.
See definition of SFlowDataSource in http://sflow.org/sflow_version_5.txt.
Signed-off-by: Neil McKee
---
lib/sflow.h | 7
ofproto/ofproto-dpif-sflow.c | 76
, bundles and more. Right now it looks to
me like the latter would be better, because it allows ofproto-dpif to
completely control what is exposed and keep a tight grip on all it's internal
pointers. But maybe there are other architectural considerations?
Neil
On Apr 24, 2013, at 11:09 AM,
that seems like a stretch --
and not worth the effort at all if you remember that the normal practice for
sFlow monitoring is to configure the same sampling rate on every port of every
switch in the LAN.
Neil
On Apr 25, 2013, at 5:06 PM, Jesse Gross wrote:
> OK, thanks for the explan
ven if the ultimate datapath output port is going to be
different. And so the revised comment should explain that if that happens the
sFlow output port is not going to be filled in, and will instead be reported
as either 0=="unknown" or 0x8001=="one interface". Did I get t
tions might not populate
every sFlow field.
Revised patch to follow.
Neil
On Apr 29, 2013, at 3:35 PM, Jesse Gross wrote:
> On Mon, Apr 29, 2013 at 2:53 PM, Neil Mckee wrote:
>> but I'm not sure I understand the one in tunnel.c. I assume you mean this
>> comment:
>>
git seemed to want to make this a series of 2 patches, and I don't know how to
argue with git. Hope that's OK.
Neil
Change sFlow packet sampling to better reflect the
per-bridge sampling that is really happening, rather than modeling it as
per-interface sampling. This fixes a
Update comments to reflect per-bridge sFlow sampling.
---
ofproto/ofproto-dpif.c | 6 +-
ofproto/tunnel.c | 1 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 3ae3532..4306d40 100644
--- a/ofproto/ofproto-dpif.c
+++
el. Note that interface-counter-polling is still handled the same
way as before,
with sFlow counter-polling data only being exported for ifIndex-interfaces.
Signed-off-by: Neil McKee
---
lib/sflow.h | 7
ofproto/ofproto-dpif-sf
traffic on different bridges (e.g. gre tunnel traffic) was
being aliased together. Given the importance of tunnel traffic...
But it's up to you.
Neil
On May 2, 2013, at 12:38 PM, Ben Pfaff wrote:
> Applied to master and branch-1.11, thanks. Do we need this on
> branch-1.10 also?
>
UXK6REbrkYI
Regards,
Neil
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On May 28, 2013, at 5:01 PM, Ben Pfaff wrote:
> On Tue, May 28, 2013 at 12:17:39PM -0700, Neil Mckee wrote:
>> It would be helpful if ovs-vsctl(1) had a way to write out the
>> netdev ifIndex numbers, where applicable, of the bridge ports. This
>> would help to harmonize
o I can
nose around?
Neil
On May 28, 2013, at 5:01 PM, Ben Pfaff wrote:
> On Tue, May 28, 2013 at 12:17:39PM -0700, Neil Mckee wrote:
>> It would be helpful if ovs-vsctl(1) had a way to write out the
>> netdev ifIndex numbers, where applicable, of the bridge ports. This
>>
,ifindex list Interface
{"data":[["br2",65534,10],["eth0",1,2],["br1",65534,9],["vm",2,11],["gre0",1,0]],"headings":["name","ofport","ifindex"]}
Signed-off-by: Neil McKee
---
vswitchd/bridge.
OK, here's how it looks now (against latest master). I wasn't sure where to
add the NEWS item so I just guessed.
Signed-off-by: Neil McKee
---
NEWS | 2 ++
vswitchd/bridge.c | 11 +++
vswitchd/vswitch.ovsschema | 7 +--
vswitchd/v
) in bridge.c:iface_refresh_status()
I should check for that? How?
(don't expect answer for at least a week)
Neil
On Jul 2, 2013, at 4:59 PM, Ben Pfaff wrote:
> Thanks Neil. I'm on vacation this week but I'll look at this when I get back
> next week.
>
> On J
Our whole team are very glad to hear that!
We expect to contribute much more to community in the future.
Thanks,
Neil
-邮件原件-
发件人: Ben Pfaff [mailto:b...@nicira.com]
发送时间: 2013年9月3日 0:35
收件人: dev@openvswitch.org
抄送: Neil Zhu; Simon Horman; Jarno Rajahalme; Casey Barker
主题: groups
visibility into
flows-in-progress, which is relevant for SDN use cases).
http://blog.sflow.com/2013/08/restflow.html
Neil
On Aug 21, 2013, at 1:50 PM, Ben Pfaff wrote:
> On Wed, Aug 21, 2013 at 01:47:45PM -0700, Romain Lenglet wrote:
>> - Original Message -
>>> From: &
there would be most appreciated.
Regards,
Neil
---
lib/odp-util.c | 15 +--
lib/odp-util.h | 3 +-
lib/sflow.h | 2 +
lib/sflow_agent.c| 15 +++
lib/sflow_api.h | 1 +
lib/sflow_receiver.c | 4 +
manpages.mk
ve to worry that the
outer traffic matrix was
being polluted with tenant address-space, and manage the resulting
state-explosion on both the
configuration and the analysis side. Better to have no option.
Neil
On Oct 7, 2013, at 9:47 AM, Jesse Gross wrote:
> On Sun, Oct 6, 2013 at 10:11
the
feed they wanted too. All without exploding the complexity of sFlow config
in OVS.
So I guess I just don't see the upside in adding options to OVS. It only
seems to be inviting a complexity explosion. Perhaps I missed something?
Neil
> On Mon, Oct 7, 2013 at 10:45 AM, Neil Mckee
Lenglet"
>>>>>>> To: "Jesse Gross"
>>>>>>> Cc: dev@openvswitch.org
>>>>>>> Sent: Friday, October 18, 2013 6:46:05 PM
>>>>>>> Subject: Re: [ovs-dev] [PATCH] sFlow export: include standard tunnel
>>>>>>&g
On Mon, Dec 24, 2012 at 11:14:15AM +0900, Akinobu Mita wrote:
> Use more preferable function name which implies using a pseudo-random
> number generator.
>
> Signed-off-by: Akinobu Mita
> Cc: Jesse Gross
> Cc: Venkat Venkatsubra
> Cc: Vlad Yasevich
> Cc: Sridhar Samu
On Tue, Dec 25, 2012 at 08:47:26PM +0900, Akinobu Mita wrote:
> 2012/12/25 Neil Horman :
> > On Mon, Dec 24, 2012 at 11:14:15AM +0900, Akinobu Mita wrote:
> >> Use more preferable function name which implies using a pseudo-random
> >> number generator.
> >&
per second.
Regards,
Neil
Neil McKee
InMon Corp.
http://www.inmon.com
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
what this is
about? I wasn't sure from the context. If this is about including the
sample_pool with every PACKET sample then it's worth considering how often it
will really be retrieved. With typical settings you will only be generating a
handful of samples per second, so retrie
re are any) and fall back on the lowest
numbered interface address (perhaps preferring IPv4 addresses over IPv6
addresses). Another approach is to choose one any way you like, but then
keep it the same for as long as that IP belongs to the switch.
Neil
On Dec 6, 2011, at 12:42 PM, Luc
On Dec 6, 2011, at 2:18 PM, Luca Giraudo wrote:
> Hi Neil,
> replies in-line.
>
> On Tue, Dec 6, 2011 at 1:43 PM, Neil Mckee wrote:
> Hi Luca,
>
> Just checking does this mean that the sFlow-agent-address might change
> just because the first collector in the l
not.
Neil
--
Signed-off-by: Neil McKee
---
COPYING |6 --
lib/sflow.h |8 ++--
lib/sflow_agent.c|8 ++--
lib/sflow_api.h |8 ++--
lib/sflow_poller.c |8 ++--
lib/sflow_receiver.c |8 ++--
lib/sflow_sampler.c
ld be welcome.
Neil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
nflow-and-sflow.html
And a first draft to define new structures for reporting OpenFlow-related data
over sFlow is here:
http://www.sflow.org/draft-sflow-openflow.txt
but given the rapid pace of OpenFlow development, this probably needs to be
reworked.
Neil
On Aug 9, 2011, at 9:42 PM, B
? It seems like it would be better if you can avoid
doing that.
Neil
On Aug 11, 2011, at 11:39 AM, Ben Pfaff wrote:
> Neil, don't worry! This really is a step forward and not a step back.
> The actions passed to the kernel and back to userspace are not really
> as helpfu
gt; of course, the IP checksum only probabilistically tells us whether
> there was a change.
This may be stating the obvious, but it's important that you never send out a
sample with the *wrong* egress port/vlan. That could break all kinds of things
(topology discovery, end-host locatio
On Aug 17, 2011, at 2:30 PM, Ben Pfaff wrote:
> On Wed, Aug 17, 2011 at 02:18:52PM -0700, Neil McKee wrote:
>>
>> On Aug 17, 2011, at 12:25 PM, Ben Pfaff wrote:
>>
>>> On Wed, Aug 17, 2011 at 11:51:05AM -0700, Pravin Shelar wrote:
>>>> On Tue, Au
On Aug 18, 2011, at 4:15 AM, Jesse Gross wrote:
> On Aug 18, 2011 12:21 AM, "Ben Pfaff" wrote:
> >
> > [bringing Neil McKee into the conversation since he knows more about
> > this than me]
> >
> > On Wed, Aug 17, 2011 at 02:17:03PM +0800, Jesse Gr
thought of all these
ramifications.
I'm still not persuaded that there's anything wrong with copying the actions to
user-space as you do now. It can continue to be an annotation that always goes
along with any sampled packets that are going there. Stuffing that other
64-bit field
On Aug 18, 2011, at 6:55 PM, Jesse Gross wrote:
> On Aug 19, 2011 6:41 AM, "Neil McKee" wrote:
> >
> >
> > On Aug 18, 2011, at 4:15 AM, Jesse Gross wrote:
> >
> >> On Aug 18, 2011 12:21 AM, "Ben Pfaff" wrote:
> >> >
> &g
tical path is the
atomic_decrement(), but it sounds like we need to rethink this and try to
avoid that atomic_decrement any way we can?
Neil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
87 matches
Mail list logo
