On Tue, 2014-02-18 at 20:35 +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 05:29:42PM +0000, Waskiewicz Jr, Peter P wrote:
> > > Its not a problem that changing the task:RMID map is expensive, what is
> > > a problem is that there's no deterministic fashion of
On Mon, 2014-01-27 at 18:34 +0100, Peter Zijlstra wrote:
Hi Peter,
First of all, sorry for the delay in responding. I've been talking with
the CPU architects to make sure we're going down the right path here
before coming back to this. Responses below.
> On Tue, Jan 14, 2014 at 09:58:26AM -0800
On Mon, 2014-01-13 at 08:55 +0100, Peter Zijlstra wrote:
> On Fri, Jan 10, 2014 at 06:55:11PM +0000, Waskiewicz Jr, Peter P wrote:
> > I've spoken with the CPU architect, and he's set me straight. I was
> > getting some simulation data and reality mixed up, so apologies.
On Tue, 2014-01-07 at 22:12 +0100, Peter Zijlstra wrote:
> Maybe its me (its late) but I can't follow.
>
> So if every cacheline is tagged with both CR3 and RMID (on all levels --
> I get that it needs to propagate etc..) then you can, upon observing a
> new CR3,RMID pair, iterate the entire cache
On Tue, 2014-01-07 at 09:34 +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 10:45:24PM +0000, Waskiewicz Jr, Peter P wrote:
> > > Since its a very limited resource that seems like a weird assumption to
> > > me; there's plenty scenarios in which you'd want to
On Mon, 2014-01-06 at 23:12 +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 09:48:29PM +0000, Waskiewicz Jr, Peter P wrote:
> > The cacheline is tagged internally with the RMID as part of the waymask
> > for the thread in the core.
> >
> > > Without a wipe yo
On Mon, 2014-01-06 at 22:26 +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 08:10:45PM +0000, Waskiewicz Jr, Peter P wrote:
> > There is one per logical CPU. However, in the current generation, they
> > report on the usage of the same L3 cache. But the CPU takes care of the
On Mon, 2014-01-06 at 19:06 +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 04:47:57PM +0000, Waskiewicz Jr, Peter P wrote:
> > > As is I don't really see a good use for RMIDs and I would simply not use
> > > them.
> >
> > If you want to use CQM in
On Mon, 2014-01-06 at 18:53 +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 04:47:57PM +0000, Waskiewicz Jr, Peter P wrote:
> > > Yeah that's not accurate, nor desired I think, because you get into
> > > horrible problems with hierarchies, do child groups belong
On Mon, 2014-01-06 at 17:41 +0100, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 04:34:04PM +0000, Waskiewicz Jr, Peter P wrote:
> > On Mon, 2014-01-06 at 12:16 +0100, Peter Zijlstra wrote:
> > > On Sun, Jan 05, 2014 at 05:23:07AM +0000, Waskiewicz Jr, Peter P wrote:
> >
On Mon, 2014-01-06 at 12:08 +0100, Peter Zijlstra wrote:
> On Fri, Jan 03, 2014 at 12:34:41PM -0800, Peter P Waskiewicz Jr wrote:
> > The CPU features themselves are relatively straight-forward, but
> > the presentation of the data is less straight-forward. Since this
> > tracks cache usage and oc
On Mon, 2014-01-06 at 12:16 +0100, Peter Zijlstra wrote:
> On Sun, Jan 05, 2014 at 05:23:07AM +0000, Waskiewicz Jr, Peter P wrote:
> > The CPU side is easy and clean. When something in the software wants to
> > monitor when a particular task is scheduled and started, write whateve
On Sat, 2014-01-04 at 17:50 -0500, Tejun Heo wrote:
> Hello,
Hi Tejun,
> On Sat, Jan 04, 2014 at 10:43:00PM +, Waskiewicz Jr, Peter P wrote:
> > Simply put, when we want to allocate an RMID for monitoring httpd
> > traffic, we can create a new child in the subsystem hierarc
On Sat, 2014-01-04 at 11:10 -0500, Tejun Heo wrote:
> Hello,
Hi Tejun,
> On Fri, Jan 03, 2014 at 12:34:41PM -0800, Peter P Waskiewicz Jr wrote:
> > The CPU features themselves are relatively straight-forward, but
> > the presentation of the data is less straight-forward. Since this
> > tracks ca
On Fri, 2013-08-16 at 09:59 -0700, Sudeep Dutt wrote:
> On Thu, 2013-08-15 at 12:14 +0200, Pavel Machek wrote:
> > Hi!
> >
>
> Hi!
>
> > > > > Since it is a PCIe card, it does not have the ability to host hardware
> > > > > devices for networking, storage and console. We provide these devices
>
On 2/24/2013 9:19 PM, Konstantin Khlebnikov wrote:
This patch fixes some annoying messages like 'Error reading PHY register' and
'Hardware Erorr' and saves several seconds on reboot.
Any networking-related patches should also include net...@vger.kernel.org.
I'm also a bit confused how the chan
On Fri, Jan 18, 2013 at 03:53:44PM -0500, Tom St Denis wrote:
> Admittedly I'm new to the kernel scene but what exactly is a "maintainer"
> then?
Maintainers are ultimately responsible for content that flows into a tree
or subsystem. That means they must command a level of expertise on
everythin
On Tue, 2013-01-15 at 19:58 +0100, Cong Ding wrote:
> If CONFIG_NF_CONNTRACK_ZONES is not defined, the variable ret might be
> uninitialized when it goes to err1 through line 125 and 263 respectively.
> So I change these goto err1 to return -EINVAL directly.
>
> Signed-off-by: Cong Ding
> ---
>
> Multiply whatever effect you think you might be able to
> measure due to that on your 2 or 4 way system, and multiple
> it up to 64 cpus or so for machines I am using. This is
> where machines are going, and is going to become the norm.
That along with speeds going to 10 GbE with multiple Tx
> Other pr_*() macros are already defined in kernel.h, but
> pr_err() was defined multiple times in several other places
>
> Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
> ---
>
> I'm writing a driver and I've been using the pr_*() macros
> from kernel.h and I was surprised not to find there p
> Ok. Thanks for clearing it up. So the idea would be that if
> pci_enable_msix() for "n" number of messages failed, then
> settle down for 1 message, which is equivalent to MSI mode
And if that fails to acquire the one vector for whatever reason (MSI
isn't enabled, or something is buggy in your
> Hmm, I see I don't understand what this driver is doing.
> What is a "struct ioatdma_device"? Is this driver requesting
> interrupts that come from the NIC or the IOAT DMA engine?
I might have caused some confusion. You had asked if any drivers
support MSI but not MSI-X, so I threw 2 driver
> -Original Message-
> From: Roland Dreier [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 20, 2007 10:43 AM
> To: Nelson, Shannon
> Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Williams, Dan J; Leech,
> Christopher; W
> -Original Message-
> From: J Hadi Salim [mailto:[EMAIL PROTECTED] On Behalf Of jamal
> Sent: Wednesday, April 25, 2007 4:37 AM
> To: Stephen Hemminger
> Cc: Waskiewicz Jr, Peter P; [EMAIL PROTECTED];
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; cramerj;
> K
> -Original Message-
> From: Patrick McHardy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 12, 2007 5:16 PM
> To: Waskiewicz Jr, Peter P
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; cramerj;
> Kok, Auke-jan H; Leech, Chri
> Thanks.
>
> > However, the PRIO qdisc still uses the priority in the bands for
> > dequeueing priority, and will feed the queues on the NIC.
> > The e1000, and any other multiqueue NIC, will schedule Tx
> based on how
> > the PRIO qdisc feeds the queues. So the only priority here is the
> >
> >>>+ skb->queue_mapping =
> >>>+
> q->prio2band[q->band2queue[band&TC_PRIO_MAX]];
> >>
> >>
> >>Does this needs to be cleared at some point again? TC actions might
> >>redirect or mirror packets to other (multiqueue) devices.
> >
> >
> > If an skb is
> Peter P Waskiewicz Jr wrote:
> > + /* To retrieve statistics per subqueue - FOR FUTURE USE */
> > + struct net_device_stats* (*get_subqueue_stats)(struct
> net_device *dev,
> > + int
> queue_index);
>
>
> Please no future use stuff, just a
> On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz
> Jr ([EMAIL PROTECTED]) wrote:
> > + alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
> > +
> > + p = kzalloc(alloc_size, GFP_KERNEL);
> > + if (!p) {
> > + printk(KERN_ERR "alloc_netdev: Unable to
>
> This indeed looks a lot better than the first patch. I'm too
> tired to fully review this now, but could you please post the
> corresponding e1000 patch? From a quick look I'm guessing
> that this patch changes the behaviour of the prio qdisc from
> strict priority to whatever scheduling mech
> Hi,
>
>
> On Apr 9 2007 14:28, Peter P Waskiewicz Jr wrote:
> >@@ -3345,6 +3358,7 @@ void free_netdev(struct net_device *dev) {
> >#ifdef CONFIG_SYSFS
> > /* Compatibility with error handling in drivers */
> >+kfree((char *)dev->egress_subqueue);
> > if (dev->reg_state == NETREG
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 09, 2007 1:47 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; cramerj; Kok, Auke-jan H; Leech, Christopher
> Su
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 09, 2007 1:38 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; cramerj; Kok, Auke-jan H; Leech, Christopher
> Su
David,
Please consider pulling from my git tree:
git-pull git://lost.foo-projects.org/~ppwaskie/git/net-2.6.22
multiqueue
This is a branch named 'multiqueue' of a recent pull from your tree with
an updated implementation of the multiqueue implementation we've been
working on. Inc
> -Original Message-
> From: Jarek Poplawski [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 12, 2007 1:58 AM
> To: Thomas Graf
> Cc: Kok, Auke-jan H; David Miller; Garzik, Jeff;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Waskiewicz Jr, Peter P; B
> -Original Message-
> From: Thomas Graf [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 09, 2007 6:35 PM
> To: Waskiewicz Jr, Peter P
> Cc: Kok, Auke-jan H; David Miller; Garzik, Jeff;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Brandeburg, Jesse; Kok
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-03-09 11:25
> > > > + }
> > > > + } else {
> > > > + /* We're not a multi-queue device. */
> > > > +
> -Original Message-
> From: Thomas Graf [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 09, 2007 5:41 AM
> To: Kok, Auke-jan H
> Cc: David Miller; Garzik, Jeff; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; Waskiewicz Jr, Peter P;
> Brandeburg, Jesse; Kok
> This is not a problem.
>
> Since the ->enqueue function stores references to the SKBs,
> any change of the dev->qdisc has to flush those references
> somehow, and it is at that point that you can fixup the skb
> queue mappings.
>
> This happens via invoking the qdisc->ops->reset() method.
>
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2007 10:22 PM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> Leech, Christopher
> Subject: Re: [PATCH 0/2] NET: Multiple
This patch applies against commit
704e0b01791bfcb75355f269a6f0054a75c9c563
of branch 'master' from davem/net-2.6.22
---
Summary:
Peter P. Waskiewicz Jr. <[EMAIL PROTECTED]>
NET: Add packet sock option to return orig_dev to userspace when
bonded
---
Add a packet socket option to allow the
IL PROTECTED]
> Sent: Monday, February 26, 2007 5:03 PM
> To: Kok, Auke-jan H
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; Waskiewicz Jr, Peter P;
> Brandeburg, Jesse; [EMAIL PROTECTED]; Ronciak, John
> Subject: Re: [PATCH 1/2] NET: Multiple
Dave,
Thanks for the feedback. Please see below for my comments /
questions.
PJ Waskiewicz
Intel Corporation
> > From: Peter Waskiewicz Jr <[EMAIL PROTECTED]>
> >
> > Added an API and associated supporting routines for
> multiqueue network
> > devices. This allows network devices sup
h's repost.
Thanks for the feedback,
PJ Waskiewicz
> -Original Message-
> From: Sreenivasa Honnur [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 23, 2007 1:01 AM
> To: Kok, Auke-jan H; David Miller; Garzik, Jeff;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.or
44 matches
Mail list logo
