This is the FINAL reminder for the call for proposals for the inaugural eBPF
Summit,
a virtual event, targeted at DevOps, platform architects and developers.
The goal is to have a gathering of users or potential users of eBPF(/XDP) as
well as
developers in order to exchange ideas, use cases
[ The deadline is this Sunday, please get your submissions in now! ]
This is the FINAL reminder for the call for proposals for the
networking and bpf track at the Linux Plumbers Conference on the wider
internet, which will be happening on August 24th-28th, 2020.
This year the technical
[ The deadline is a week and a half away, please get your submissions
in soon! ]
This is a reminder for the call for proposals for the networking and
bpf track at the Linux Plumbers Conference on the wider internet,
which will be happening on August 24th-28th, 2020.
This year the technical
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "net/rxrpc" subs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the distinct crashes that syzbot has seen in the last week, I've manually
marked 6 of them as possibly being bugs in the "net/tls" subsystem
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the distinct crashes that syzbot has seen in the last week, I've manually
marked 8 of them as possibly being bugs in the "net/bpf" subsystem
t: Linux Plumbers BPF micro-conference CFP (reminder)
> To:
> Cc: , ,
> , ,
> ,
>
>
> This is a call for proposals for the BPF micro-conference at this
> years' Linux Plumbers Conference (LPC) 2019 which will be held in
> Lisbon, Portugal for September 9-11.
>
> The g
Hello
Please i still await your response regarding my previous email.
Hello
Please i still await your response regarding my previous email.
Hello
Please i still await your response regarding my previous email.
From: Cristal Tiscareno
Sent: Wednesday, December 06, 2017 2:29 PM
Subject: OUMM: Email Reminder to Voluntarily Update Disability and Veteran
Status
TO: All Employees
To comply with federal data collection requirements related to laws regulating
anti
Hello,
We'd like to remind you that Netdev 2.2 is fast approaching. It's
November 8th-10th, 2017 in Seoul, Korea.
There is still plenty time to register at
https://onlineregistrations.ca/netdev22/ !
We have amazing content lined up for the conference. Please check out
https://www.netdevconf.org/
Can you ask internally on how openview would handle this? It carriers
the major chunk of management tools market so it may provide good
insight.
I've asked the question in an internal, informal communications channel.
No guarantees it will reach any OpenView types, but if it does I'll try
t
> The current patch is fine if your hardware implements the required atomicity
> itself.
Near all do optionally, but it would make increasing the statistics a magnitude
more expensive.
Atomic operations don't come cheap on modern systems. And you would need
to change the fast path increments
On Wednesday 24 May 2006 22:08, Jeff Garzik wrote:
> Brent Cook wrote:
> > Note that this is just clearing the hardware statistics on the interface,
> > and
> > would not require any kind of atomic_increment addition for interfaces that
> > support that. It would be kind-of awkward to implement
On Wednesday 24 May 2006 10:01, Phil Dibowitz wrote:
> David Miller wrote:
> > Some time in the next few weeks, it is likely that the 2.6.18
> > merge window will open up shortly after a 2.6.17 release.
> >
> > So if you have major 2.6.18 submissions planned for the networking,
> > you need to sta
Brian Haley wrote:
> jamal wrote:
>> On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
>>
>>> Right, I'm aware there are other ways of doing this - I've written
>>> scripts to
>>> record a hundreds of numbers, and then subtract them from each other.
>>> But
>>> those scripts are work arounds
From: Phil Dibowitz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 14:04:12 -0700
> why would specifically not support a _feature_ of the hardware.
Sparc64 chips support a hash table like hw assist feature for TLB
reloading, I didn't use it for 8+ years and went with a virtual page
table approach ins
On Thu, May 25, 2006 at 01:29:28PM -0700, David Miller wrote:
> From: Phil Dibowitz <[EMAIL PROTECTED]>
> Date: Thu, 25 May 2006 12:22:39 -0700
>
> > So at least, for the _current_ implimentations, this should have no
> > performance impacts.
>
> Regardless, I think this is something that userspa
From: Phil Dibowitz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 12:22:39 -0700
> So at least, for the _current_ implimentations, this should have no
> performance impacts.
Regardless, I think this is something that userspace _can_
take care of reasonably and therefore has no buisness in the
kernel
On Thu, May 25, 2006 at 01:41:41PM -0500, Brent Cook wrote:
> On Thursday 25 May 2006 12:59, Phil Dibowitz wrote:
> > On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > > > I'll admit to not knowing all the intricacies of the kernel coding
> > > > involved, but I don't offhand see how
On Thursday 25 May 2006 12:59, Phil Dibowitz wrote:
> On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > > I'll admit to not knowing all the intricacies of the kernel coding
> > > involved, but I don't offhand see how zeroing the stats would be
> > > significantly more complex than upd
On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > I'll admit to not knowing all the intricacies of the kernel coding
> > involved, but I don't offhand see how zeroing the stats would be
> > significantly more complex than updating the stats during normal usage.
> > But I'll have to l
Can you ask internally on how openview would handle this? It carriers the
major chunk of management tools market so it may provide good insight.
I've asked the question in an internal, informal communications channel.
No guarantees it will reach any OpenView types, but if it does I'll
try to
On Thu, 25 May 2006, Brent Cook wrote:
> On Thursday 25 May 2006 02:23, Bill Fink wrote:
> > On Wed, 24 May 2006, Jeff Garzik wrote:
> > > Brent Cook wrote:
> > > > Note that this is just clearing the hardware statistics on the
> > > > interface, and would not require any kind of atomic_increment
On Wed, 2006-24-05 at 13:25 -0700, Rick Jones wrote:
> The lanadmin (think ethtool) command of HP-UX has had a way to clear the
> statistics reported by lanadmin. I do not know however, if that affects
> the stats in the actual SNMP interface MIBs as I've never had occasion
> to look.
>
> I s
On Thu, 2006-05-25 at 03:23 -0400, Bill Fink wrote:
> likely problem areas. The human mind (at least speaking for myself) is
> not nearly as adept when having to deal with deltas. Yes, you can record
> the initial state of all the devices, run the stress test, record the new
> state of all the de
On Thursday 25 May 2006 02:23, Bill Fink wrote:
> On Wed, 24 May 2006, Jeff Garzik wrote:
> > Brent Cook wrote:
> > > Note that this is just clearing the hardware statistics on the
> > > interface, and would not require any kind of atomic_increment addition
> > > for interfaces that support that. I
Phil Dibowitz <[EMAIL PROTECTED]> :
[...]
> Right. I think the point here is that it does _NOT_ inherently break
> things. If you don't like the behavior, don't run "ethtool -z eth0",
> it's that simple.
It would be better to explain why several sysadmins want this feature
and why it can't be done
On Wed, 24 May 2006, Phil Dibowitz wrote:
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding
On Wed, 24 May 2006, Phil Dibowitz wrote:
> Right. I think the point here is that it does _NOT_ inherently break
> things. If you don't like the behavior, don't run "ethtool -z eth0",
> it's that simple.
>
> A co-worker suggested today, that maybe it'd appease people if the final
> ethtool patch
On Wed, 24 May 2006, Jeff Garzik wrote:
> Brent Cook wrote:
> > Note that this is just clearing the hardware statistics on the interface,
> > and
> > would not require any kind of atomic_increment addition for interfaces that
> > support that. It would be kind-of awkward to implement this on dr
Phil Dibowitz wrote:
As for the clearing, in this case, the clearing is done by a command to
the hardware - and I believe the hardware does that atomically. However,
I could certainly add a spinlock around it if someone sees a need.
No, because then you'd also have to add the spin-lock in the
Brian Haley wrote:
>
> I don't have any problem with Phil's changes.
Thanks Brian, and Andy, and Ben for your support and ideas.
> So how is this different than if an SNMP station probes my system,
> then I reboot, then they probe again. Things will seem to have gone
> backwards, but they deal w
Rick Jones wrote:
Phil Dibowitz wrote:
Does having the ability to boot into single user mode break
networking? No, it
*allows* you to break networking. Does the _support_ of rmmod break the
kernel? No, but it *allows* you to.
Are SNMP traps generated by going into single-user mode? Rather
Phil Dibowitz wrote:
Well, I can show you support on my home switch (cabletron) - the network guys
will be a little unhappy if I clear stats on our production network (cisco)
without warning them:
Isn't that last bit an example of why it might not be good to play-out
that rope?-)
Does havin
So how is this different than if an SNMP station probes my system, then
I reboot, then they probe again. Things will seem to have gone
backwards, but they deal with that just fine.
In that case hasn't the system's uptime and/or last boot time in the MIB
changed and so indicates to the managem
On Wed, 2006-05-24 at 14:23 -0400, Jeff Garzik wrote:
> I disagree that we should bother about clearing statistics. It always
> adds more complication than necessary. Few (if any) other statistics in
> Linux permit easy clearing,
iptables -Z
> often because adding operations other than
> '
On Wed, May 24, 2006 at 04:10:32PM -0400, jamal wrote:
> Can you provide some link to a vendor that allows resetting ethernet
> stats? I am almost certain, if they do they will have something or other
> which indicates that such a reset happened. It is also easier for cisco
> to have none standard
jamal wrote:
On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
Right, I'm aware there are other ways of doing this - I've written scripts to
record a hundreds of numbers, and then subtract them from each other. But
those scripts are work arounds
I don't have any problem with Phil's cha
Can you provide some link to a vendor that allows resetting ethernet
stats? I am almost certain, if they do they will have something or other
which indicates that such a reset happened. It is also easier for cisco
to have none standard feature "as of ios 15.16" which could support such
behavior be
On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
>
> Right, I'm aware there are other ways of doing this - I've written scripts to
> record a hundreds of numbers, and then subtract them from each other. But
> those scripts are work arounds
It is not a work around, _it is design intent_.
Brent Cook wrote:
Note that this is just clearing the hardware statistics on the interface, and
would not require any kind of atomic_increment addition for interfaces that
support that. It would be kind-of awkward to implement this on drivers that
increment stats in hardware though (lo, vlan,
On Wednesday 24 May 2006 14:14, Phil Dibowitz wrote:
> On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote:
> > Phil Dibowitz wrote:
> > Given any method of clearing statistics across your cluster, I'm certain
> > you can come up with a similar method of obtaining the current statistic
> >
On Wed, May 24, 2006 at 03:05:54PM -0400, Jeff Garzik wrote:
> Phil Dibowitz wrote:
> >On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
> >>I disagree that we should bother about clearing statistics. It always
> >>adds more complication than necessary. Few (if any) other statistics i
Phil Dibowitz wrote:
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding operations other tha
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
> I disagree that we should bother about clearing statistics. It always
> adds more complication than necessary. Few (if any) other statistics in
> Linux permit easy clearing, often because adding operations other than
> 'increment'
Those folks wanting link-level stats over an interval (I'm assuming that
is wny someone would want to zero stats?) should feel free to embrace
and extend beforeafter:
ftp://ftp.cup.hp.com/dist/networking/tools/
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
Phil Dibowitz wrote:
David Miller wrote:
Some time in the next few weeks, it is likely that the 2.6.18
merge window will open up shortly after a 2.6.17 release.
So if you have major 2.6.18 submissions planned for the networking,
you need to start thinking about getting it to me now.
There is a
On Wed, 2006-24-05 at 01:01 -0700, Phil Dibowitz wrote:
[..]
>
> For your reference, here's the two times I've posted it this month - I'm
> happy to send it along again.
The problem with resetting stats is it is _most definetely_ going to
break management apps like SNMP.
This is not to say this
David Miller wrote:
> Some time in the next few weeks, it is likely that the 2.6.18
> merge window will open up shortly after a 2.6.17 release.
>
> So if you have major 2.6.18 submissions planned for the networking,
> you need to start thinking about getting it to me now.
>
> There is a 2.6.18 tr
51 matches
Mail list logo
