Re: [PATCH v4 11/13] task_isolation: net: don't flush backlog on CPUs running isolated tasks

2021-01-22 Thread Marcelo Tosatti
On Thu, Oct 01, 2020 at 04:47:31PM +0200, Frederic Weisbecker wrote: > On Wed, Jul 22, 2020 at 02:58:24PM +, Alex Belits wrote: > > From: Yuri Norov > > > > so we don't need to flush it. > > What guarantees that we have no backlog on it? >From Paolo's work to use lockless reading of per-C

Re: [EXT] Re: [PATCH v5 9/9] task_isolation: kick_all_cpus_sync: don't kick isolated cpus

2021-01-22 Thread Marcelo Tosatti
On Tue, Nov 24, 2020 at 12:21:06AM +0100, Frederic Weisbecker wrote: > On Mon, Nov 23, 2020 at 10:39:34PM +, Alex Belits wrote: > > > > On Mon, 2020-11-23 at 23:29 +0100, Frederic Weisbecker wrote: > > > External Email > > > > > > --

Re: [PATCH net-next v2 0/3] net: introduce rps_default_mask

2020-11-04 Thread Marcelo Tosatti
On Wed, Nov 04, 2020 at 06:36:08PM +0100, Paolo Abeni wrote: > On Tue, 2020-11-03 at 08:52 -0800, Jakub Kicinski wrote: > > On Tue, 03 Nov 2020 16:22:07 +0100 Paolo Abeni wrote: > > > The relevant use case is an host running containers (with the related > > > orchestration tools) in a RT environmen

Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs

2020-10-27 Thread Marcelo Tosatti
On Mon, Oct 26, 2020 at 06:22:29PM -0400, Nitesh Narayan Lal wrote: > > On 10/26/20 5:50 PM, Thomas Gleixner wrote: > > On Mon, Oct 26 2020 at 14:11, Jacob Keller wrote: > >> On 10/26/2020 1:11 PM, Thomas Gleixner wrote: > >>> On Mon, Oct 26 2020 at 12:21, Jacob Keller wrote: > Are there driv

Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs

2020-10-27 Thread Marcelo Tosatti
On Mon, Oct 26, 2020 at 08:00:39PM +0100, Thomas Gleixner wrote: > On Mon, Oct 26 2020 at 14:30, Marcelo Tosatti wrote: > > On Fri, Oct 23, 2020 at 11:00:52PM +0200, Thomas Gleixner wrote: > >> So without information from the driver which tells what the best number > >&

Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs

2020-10-26 Thread Marcelo Tosatti
On Fri, Oct 23, 2020 at 11:00:52PM +0200, Thomas Gleixner wrote: > On Fri, Oct 23 2020 at 09:10, Nitesh Narayan Lal wrote: > > On 10/23/20 4:58 AM, Peter Zijlstra wrote: > >> On Thu, Oct 22, 2020 at 01:47:14PM -0400, Nitesh Narayan Lal wrote: > >> So shouldn't we then fix the drivers / interface fi

Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs

2020-10-22 Thread Marcelo Tosatti
On Wed, Oct 21, 2020 at 10:25:48PM +0200, Thomas Gleixner wrote: > On Tue, Oct 20 2020 at 20:07, Thomas Gleixner wrote: > > On Tue, Oct 20 2020 at 12:18, Nitesh Narayan Lal wrote: > >> However, IMHO we would still need a logic to prevent the devices from > >> creating excess vectors. > > > > Manage

Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs

2020-10-19 Thread Marcelo Tosatti
On Mon, Oct 19, 2020 at 01:11:37PM +0200, Peter Zijlstra wrote: > On Sun, Oct 18, 2020 at 02:14:46PM -0400, Nitesh Narayan Lal wrote: > > >> +hk_cpus = housekeeping_num_online_cpus(HK_FLAG_MANAGED_IRQ); > > >> + > > >> +/* > > >> + * If we have isolated CPUs for use by real-

Re: [RFC][Patch v1 2/3] i40e: limit msix vectors based on housekeeping CPUs

2020-09-11 Thread Marcelo Tosatti
rs to reach as close as we can to the >* number of online CPUs. >*/ > - cpus = num_online_cpus(); > + cpus = num_housekeeping_cpus(); > pf->num_lan_msix = min_t(int, cpus, vectors_left / 2); > vectors_left -= pf->num_lan_msix; > > -- > 2.27.0 For patches 1 and 2: Reviewed-by: Marcelo Tosatti

Re: [RFC][Patch v1 3/3] PCI: Limit pci_alloc_irq_vectors as per housekeeping CPUs

2020-09-10 Thread Marcelo Tosatti
On Wed, Sep 09, 2020 at 11:08:18AM -0400, Nitesh Narayan Lal wrote: > This patch limits the pci_alloc_irq_vectors max vectors that is passed on > by the caller based on the available housekeeping CPUs by only using the > minimum of the two. > > A minimum of the max_vecs passed and available housek

[PATCH] Marvell Libertas 8388 802.11b/g USB driver (v3)

2007-02-10 Thread Marcelo Tosatti
Hi, Here goes an updated patch of the Marvell Libertas 8388 802.11 USB driver, addressing pretty much all comments from Arnd (the remaining ones are listed in TODO entry below). Diff can be found at http://dev.laptop.org/~marcelo/libertas-8388-10022007.patch Please review. TODO: - In places wh

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-02-10 Thread Marcelo Tosatti
On Sat, Jan 27, 2007 at 02:53:07AM +0100, Arnd Bergmann wrote: > > +/** Command Processing States and Options */ > > +#define HostCmd_STATE_IDLE0x > > +#define HostCmd_STATE_IN_USE_BY_HOST 0x0001 > > +#define HostCmd_STATE_IN_USE_BY_MINIPORT 0x0002 > > +#define

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-02-06 Thread Marcelo Tosatti
On Sat, Feb 03, 2007 at 08:43:49PM -0200, Marcelo Tosatti wrote: > Hi Arnd, > > Most of these are unused as well, I guess it would be good > > to go through the whole list and see what can be removed. > > Done. Will go through the entire file list before posting the next >

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-02-03 Thread Marcelo Tosatti
Hi Arnd, On Sat, Jan 27, 2007 at 02:53:07AM +0100, Arnd Bergmann wrote: > On Tuesday 16 January 2007 19:55, Marcelo Tosatti wrote: > > > > Announcing an updated patch of the Marvell Libertas 8388 802.11 USB > > driver. > > > > Diff can be found at > >

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-31 Thread Marcelo Tosatti
Hi Jiri, On Sat, Jan 20, 2007 at 06:15:54PM -0200, Marcelo Tosatti wrote: > On Wed, Jan 17, 2007 at 04:43:28PM +0100, Jiri Benc wrote: > > On Wed, 17 Jan 2007 10:01:12 -0500, Dan Williams wrote: > > > But could we please be constructive here, and actually take a look at > >

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-24 Thread Marcelo Tosatti
On Thu, Jan 18, 2007 at 03:22:50AM -0500, John W. Linville wrote: > On Wed, Jan 17, 2007 at 06:19:07PM -0500, Jeff Garzik wrote: > > Christoph Hellwig wrote: > > >On Wed, Jan 17, 2007 at 01:00:47PM -0500, Dan Williams wrote: > > > >>allows the 8388 to continue routing other laptops' packets over t

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-22 Thread Marcelo Tosatti
On Wed, Jan 17, 2007 at 06:01:24PM +, Johannes Berg wrote: > > 3) Could you enumerate your issues with the command dispatching? Right > > now, many of the commands are blocking, which is suboptimal. This is an > > artifact of the embedded history of the part. We need to eventually fix > > t

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-22 Thread Marcelo Tosatti
On Wed, Jan 17, 2007 at 06:01:24PM +, Johannes Berg wrote: > On Wed, 2007-01-17 at 12:43 -0500, Dan Williams wrote: > > > I said "mostly" fullmac. Sort of like ipw2100 (IIRC) is softmac but it > > does all the association stuff in firmware. It doesn't fit fullmac, but > > it's a lot more ful

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-20 Thread Marcelo Tosatti
Resending, apparently the first message got dropped somehow... From: Marcelo Tosatti <[EMAIL PROTECTED]> Date: Thu, 18 Jan 2007 13:02:13 -0200 To: Jiri Benc <[EMAIL PROTECTED]> Cc: Dan Williams <[EMAIL PROTECTED]>, Marcelo Tosatti <[EMAIL PROTECTED]>, netd

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-20 Thread Marcelo Tosatti
Got dropped somehow... - Forwarded message from Marcelo Tosatti <[EMAIL PROTECTED]> - Date: Thu, 18 Jan 2007 13:43:51 -0200 To: Jiri Benc <[EMAIL PROTECTED]> Cc: Dan Williams <[EMAIL PROTECTED]>, Johannes Berg <[EMAIL PROTECTED]>, Marcelo T

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-17 Thread Marcelo Tosatti
On Wed, Jan 17, 2007 at 07:52:13AM +, Johannes Berg wrote: > On Tue, 2007-01-16 at 16:55 -0200, Marcelo Tosatti wrote: > > > _Please_ review, this driver is targeted for mainline inclusion. > > > > There have been almost no comments resulting from the first submis

[PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

2007-01-16 Thread Marcelo Tosatti
Announcing an updated patch of the Marvell Libertas 8388 802.11 USB driver. Diff can be found at http://dev.laptop.org/~marcelo/libertas-8388-16012007.patch _Please_ review, this driver is targeted for mainline inclusion. There have been almost no comments resulting from the first submission.

Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver

2006-12-18 Thread Marcelo Tosatti
> > > /* Channel flags. */ > > Did you send this part to netbsd also? We really don't want to fork > > radiotap. ;) Also, this should be in a separate patch, but I'm guessing > > it's > > all rolled together for convenience. > > No, especially since NetBSD is where I keep the authoritative def

[PATCH] Marvell Libertas 8388 802.11b/g USB driver

2006-12-15 Thread Marcelo Tosatti
Hi, Marvell released a GPL driver for their 8388 wireless chip for USB interface back in April. The 8388 is the device being used by the OLPC laptop. We have been working on cleaning it up for mainline inclusion. I think the moment for wider review has arrived. Since the diff is pretty large (

Re: [PATCH-2.4] forcedeth update to 0.50

2006-05-31 Thread Marcelo Tosatti
On Wed, May 31, 2006 at 09:43:45PM +0200, Willy Tarreau wrote: > On Wed, May 31, 2006 at 09:50:38PM +0200, Manfred Spraul wrote: > > Marcelo Tosatti wrote: > > > > >Since v2.4.33 should be out RSN, my opinion is that applying the > > >one-liner to fix the bringu

Re: [PATCH-2.4] forcedeth update to 0.50

2006-05-31 Thread Marcelo Tosatti
On Wed, May 31, 2006 at 07:54:38AM +0200, Willy Tarreau wrote: > On Wed, May 31, 2006 at 07:50:32AM +0200, Manfred Spraul wrote: > > Hi Willy, > > > > Willy Tarreau wrote: > > > > >I started from the latest backport you sent in september (0.42) and > > >incrementally applied 2.6 updates. I stoppe

Re: [PATCH,2.4,SECURITY,NET] orinoco: CVE-2005-3180: Information leakage due to incorrect padding

2006-02-15 Thread Marcelo Tosatti
On Wed, Feb 08, 2006 at 06:35:27PM +0900, Horms wrote: > > [PATCH] Better fixup for the orinoco driver > > > > The latest kernel added a pretty ugly fix for the orinoco etherleak bug > > which contains bogus skb->len checks already done by the caller and causes > > copies of all odd sized frames (