On Thu, Feb 29, 2024 at 3:53 PM Eric Dumazet wrote:
>
> On Thu, Feb 29, 2024 at 3:47 PM Jakub Kicinski wrote:
> >
> > On Thu, 29 Feb 2024 09:55:22 +0100 Eric Dumazet wrote:
> > > I do not see other solution than this, otherwise we have to add more
> > > po
On Thu, Feb 29, 2024 at 3:47 PM Jakub Kicinski wrote:
>
> On Thu, 29 Feb 2024 09:55:22 +0100 Eric Dumazet wrote:
> > I do not see other solution than this, otherwise we have to add more
> > pollution to include/linux/netdevice.h
>
> Right :(
>
> > diff --git a/in
IZER’
> smp_store_release(&p, RCU_INITIALIZER((typeof(p))_r_a_p__v)); \
> ^~~
> net/core/dev.c:9081:2: note: in expansion of macro ‘rcu_assign_pointer’
>rcu_assign_pointer(dev->dpll_pin, dpll_pin);
>^~
>
> O
On Wed, Feb 28, 2024 at 3:07 PM Vadim Fedorenko
wrote:
>
> On 28/02/2024 11:09, Tasmiya Nalatwad wrote:
> > Greetings,
> >
> > [revert 0d60d8df6f49] [net/net-next] [6.8-rc5] Build Failure
> >
> > Reverting below commit fixes the issue
> >
> > commit 0d60d8df6f493bb46bf5db40d39dd60a1bafdd4e
> >
On Sun, Oct 8, 2023 at 8:27 PM Christian Marangi wrote:
>
> On Sun, Oct 08, 2023 at 09:08:41AM +0200, Eric Dumazet wrote:
> > On Fri, Oct 6, 2023 at 8:49 PM Christian Marangi
> > wrote:
> > >
> > > On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wro
On Fri, Oct 6, 2023 at 8:49 PM Christian Marangi wrote:
>
> On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wrote:
> > On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi
> > wrote:
> > >
> > > Replace if condition of napi_schedule_prep/__napi_schedule a
On Fri, Oct 6, 2023 at 8:52 PM Christian Marangi wrote:
>
> On Thu, Oct 05, 2023 at 06:41:03PM +0200, Eric Dumazet wrote:
> > On Thu, Oct 5, 2023 at 6:32 PM Jakub Kicinski wrote:
> > >
> > > On Thu, 5 Oct 2023 18:11:56 +0200 Eric Dumazet wrote:
> >
On Thu, Oct 5, 2023 at 6:32 PM Jakub Kicinski wrote:
>
> On Thu, 5 Oct 2023 18:11:56 +0200 Eric Dumazet wrote:
> > OK, but I suspect some users of napi_reschedule() might not be race-free...
>
> What's the race you're thinking of?
This sort of thing... the rac
On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi wrote:
>
> Replace if condition of napi_schedule_prep/__napi_schedule and use bool
> from napi_schedule directly where possible.
>
> Signed-off-by: Christian Marangi
> ---
> drivers/net/ethernet/atheros/atlx/atl1.c | 4 +---
> drivers/net/ethe
Kleine-Budde # for can/dev/rx-offload.c
OK, but I suspect some users of napi_reschedule() might not be race-free...
Reviewed-by: Eric Dumazet
On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi wrote:
>
> Replace drivers that still use napi_schedule_prep/__napi_schedule
> with napi_schedule helper as it does the same exact check and call.
>
> Signed-off-by: Christian Marangi
Reviewed-by: Eric Dumazet
has been scheduled.
> been scheduled.
>
> Signed-off-by: Christian Marangi
Yeah, I guess you forgot to mention I suggested this patch ...
Reviewed-by: Eric Dumazet
On 8/21/20 8:12 AM, Nicholas Piggin wrote:
> Support huge page vmalloc mappings. Config option HAVE_ARCH_HUGE_VMALLOC
> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> supports PMD sized vmap mappings.
>
> vmalloc will attempt to allocate PMD-sized pages if allocating PMD
7a5063af47438b626bc47cbd u64_stats: provide u64_stats_t
> type
>
>
Fix has been sent few days ago.
For some reason the linuxppc-dev@lists.ozlabs.org list has not received the
patch.
>From 47c47befdcf31fb8498c9e630bb8e0dc3ef88079 Mon Sep 17 00:00:00 2001
From: Eric Dumazet
Dat
;
> #define LOCAL_INIT(i){ (i) }
>
> -static __inline__ long local_read(local_t *l)
> +static __inline__ long local_read(const local_t *l)
> {
> return READ_ONCE(l->v);
> }
>
I have sent this patch two days ago, I do not believe I had any answer from ppc
maintainers.
>
On 11/01/2018 09:32 AM, Peter Zijlstra wrote:
>> Anyhow, if the atomic maintainers are willing to stand up and state for
>> the record that the atomic counters are guaranteed to wrap modulo 2^n
>> just like unsigned integers, then I'm happy to take Paul's patch.
>
> I myself am certainly relyi
On Mon, Oct 29, 2018 at 11:43 PM Abdul Haleem
wrote:
>
> Greeting's
>
> mainline build fails on my powerpc with commit 55469b : drivers: net:
> remove inclusion when not needed
>
> Machine type: PowerPC power 8 bare-metal
> kernel : 4.19.0
> gcc : 4.8.5
> config attached
>
Thanks for the report
On 06/19/2018 03:32 PM, Andreas Schwab wrote:
> On Jun 19 2018, Eric Dumazet wrote:
>
>> diff --git a/drivers/net/ethernet/sun/sungem.c
>> b/drivers/net/ethernet/sun/sungem.c
>> index
>> 7a16d40a72d13cf1d522e8a3a396c826fe76f9b9..672d6748ab44f0890e92d5ca55d6ff
On 06/19/2018 01:10 PM, Eric Dumazet wrote:
>
>
> On 06/19/2018 12:10 PM, Andreas Schwab wrote:
>> On Jun 18 2018, Eric Dumazet wrote:
>>
>>> DUMP_PREFIX_ADDRESS might give us more information (say alignment problem,
>>> or crossing page boundaries)
&
On 06/19/2018 12:10 PM, Andreas Schwab wrote:
> On Jun 18 2018, Eric Dumazet wrote:
>
>> DUMP_PREFIX_ADDRESS might give us more information (say alignment problem,
>> or crossing page boundaries)
>
> DUMP_PREFIX_ADDRESS is useless for that purpose.
>
> Here ar
On 06/18/2018 04:29 PM, Eric Dumazet wrote:
>
>
> On 06/18/2018 11:45 AM, Mathieu Malaterre wrote:
>
>>
>> Here is what I get on my side
>>
>> [ 53.628847] sungem: sungem wrong csum : 4e04/f97, len 64 bytes
>> [ 53.667063] sungem: su
On 06/18/2018 11:45 AM, Mathieu Malaterre wrote:
>
> Here is what I get on my side
>
> [ 53.628847] sungem: sungem wrong csum : 4e04/f97, len 64 bytes
> [ 53.667063] sungem: sungem wrong csum : eea8/6eec, len 149 bytes
> [ 58.648952] sungem: sungem wrong csum : 2095/3d06, len 64 bytes
>
On 06/18/2018 10:54 AM, Andreas Schwab wrote:
> On Jun 17 2018, Eric Dumazet wrote:
>
>> Oh this is silly, please try :
>>
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index
>> c642304f178ce0a4e1358d59e45032a39f76fb3f..54dd9c18ecad817812898d6f
On 06/17/2018 03:27 AM, Andreas Schwab wrote:
>
> That doesn't change anything.
OK, thanks !
Oh this is silly, please try :
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index
c642304f178ce0a4e1358d59e45032a39f76fb3f..54dd9c18ecad817812898d6f335e1794a07dabbe
100644
--- a/net/core/skb
On 06/16/2018 12:14 AM, Mathieu Malaterre wrote:
> Hi Eric,
>
> On Fri, Jun 15, 2018 at 9:14 PM Eric Dumazet wrote:
>>
>>
>>
>> On 06/15/2018 11:56 AM, Mathieu Malaterre wrote:
>>> This reverts commit 88078d98d1bb085d72af8437707279e203524fa5.
>
Hi all
Is anybody working on adding QUEUED spinlocks to powerpc 64bit ?
I've seen past attempts with ticket spinlocks
( https://patchwork.ozlabs.org/patch/449381/ and other related links )
But it looks ticket spinlocks are a thing of the past.
Thanks.
On Thu, 2016-10-27 at 12:54 -0500, Thomas Falcon wrote:
> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
> > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
> >> We recently encountered a bug where a few customers using ibmveth on the
> >> same LPAR hit an issue wh
On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
> We recently encountered a bug where a few customers using ibmveth on the
> same LPAR hit an issue where a TCP session hung when large receive was
> enabled. Closer analysis revealed that the session was stuck because the
> one side was adver
On Wed, 2016-08-24 at 06:07 -0700, Eric Dumazet wrote:
> I am afraid you could live lock here on SMP.
>
> You should make sure you do not loop forever, not assuming cpu is faster
> than NIC.
You are protected by the tx_lock spinlock, but this is fragile as you
could very well
On Wed, 2016-08-24 at 12:36 +0200, Christophe Leroy wrote:
> Initially, a NAPI TX routine has been implemented separately from
> NAPI RX, as done on the freescale/gianfar driver.
>
> By merging NAPI RX and NAPI TX, we reduce the amount of TX completion
> interrupts.
>
> Handling of the budget in
On Tue, 2016-04-12 at 14:38 -0500, John Allen wrote:
> Moves tx completion processing out of interrupt context, deferring work
> using a wait queue. With this work now deferred, we must account for the
> possibility that skbs can be sent faster than we can process completion
> requests in which cas
On Tue, 2016-01-05 at 16:23 +0100, Rabin Vincent wrote:
> The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data
> instructions since it XORs A with X while all the others replace A with
> some loaded value. All the BPF JITs fail to clear A if this is used as
> the first instruction i
On Wed, 2015-07-15 at 12:52 +0300, Konstantin Khlebnikov wrote:
> These functions check should_resched() before unlocking spinlock/bh-enable:
> preempt_count always non-zero => should_resched() always returns false.
> cond_resched_lock() worked iff spin_needbreak is set.
Interesting, this definite
On Mon, 2015-06-15 at 13:40 +, Madalin-Cristian Bucur wrote:
> > -Original Message-
> > From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> >
> > On Wed, 2015-04-29 at 17:56 +0300, Madalin Bucur wrote:
> > > This introduces the Freescale Da
On Wed, 2015-04-29 at 17:56 +0300, Madalin Bucur wrote:
> This introduces the Freescale Data Path Acceleration Architecture
> (DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan,
> BMan, PAMU and FMan drivers to deliver Ethernet connectivity on
> the Freescale DPAA QorIQ platforms.
...
On Wed, 2015-06-10 at 07:38 +, Madalin-Cristian Bucur wrote:
> Hi Eric,
>
> Can you please tell us if this change would be for the better?
>
> I was about to say yes to this request but checked and no other Ethernet
> driver seems to use the queue trans_start.
> I was able to find your patch
On Mon, 2015-04-27 at 17:10 -0500, Thomas Falcon wrote:
> + if (be16_to_cpu(skb->protocol) == ETH_P_IP) {
> + skb_set_network_header(skb, 0);
> + skb_set_transport_header(skb,
> sizeof(struct ip
On Tue, 2015-04-14 at 15:35 -0500, Thomas Falcon wrote:
> Enables receiving large packets from other LPARs. These packets
> have a -1 IP header checksum, so we must recalculate to have
> a valid checksum.
>
> Signed-off-by: Brian King
> Signed-off-by: Thomas Falcon
> ---
> drivers/net/ethernet/
eeing
>
> tested on x86_64 and i386
>
> Signed-off-by: Alexei Starovoitov
Acked-by: Eric Dumazet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 2013-10-03 at 21:11 -0700, Alexei Starovoitov wrote:
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index a6ac848..5d66cd9 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -25,15 +25,20 @@ struct sk_filter
> {
> atomic_trefc
at the syscall entrypoints. It
> > also reverts some unnecessary checks in sys_socketcall.
> >
> > Apparently I was suffering from underscore blindness the first time around.
> >
> > Signed-off-by: Andy Lutomirski
>
> Eric, can you test this patch too?
Yes, this fixe
On Thu, 2013-06-06 at 12:56 +1000, Michael Neuling wrote:
> On Thu, May 23, 2013 at 7:07 AM, Andy Lutomirski wrote:
> > MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
> > it's a hack that steals a bit to indicate to other networking code
> > that a compat entry was used. So don'
On Fri, 2013-05-03 at 15:29 +0100, David Laight wrote:
> > > Could ppc64 experts confirm using byte is safe, or should we really add
> > > a 32bit hole after the spinlock ? If so, I wonder how many other places
> > > need a change...
> ...
> > Also I'd be surprised if ppc64 is the only one with tha
On Fri, 2013-05-03 at 11:01 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 10:04:32PM -0700, Eric Dumazet wrote:
> > These kind of errors are pretty hard to find, its a pity to spend time
> > on them.
>
> Well, yes. From the first comment in gcc PR52080. "For t
On Wed, 2013-05-01 at 16:53 +0100, David Laight wrote:
> Why not just change gc_candidate and gc_maybe_cycle to
> unsigned char?
> It might reduce the number of pad bytes somewhat.
You didn't quite follow the discussion.
I used bytes on V1, and we are not 100% sure its safe on all arches.
unsign
can use the non atomic __set_bit()/__clear_bit().
recursion_level can share the same 64bit location with the spinlock,
as it is set only with this spinlock held.
[1] bug fixed in gcc-4.8.0 :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Reported-by: Ambrose Feinstein
Signed-off-by: Eric
On Wed, 2013-05-01 at 13:24 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
> > li 11,1
> > ld 0,0(9)
> > rldimi 0,11,31,32
> > std 0,0(9)
> > blr
> > .ident "GCC: (GNU) 4.6.3"
> &
On Wed, 2013-05-01 at 11:51 +1000, Anton Blanchard wrote:
> Hi Eric,
>
> > From: Eric Dumazet
> >
> > Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> > instructions to manipulate them. If the 64bit word includes any
> > atomic_t
From: Eric Dumazet
Using bit fields is dangerous on ppc64, as the compiler uses 64bit
instructions to manipulate them. If the 64bit word includes any
atomic_t or spinlock_t, we can lose critical concurrent changes.
This is happening in af_unix, where unix_sk(sk)->gc_candidate/
gc_maybe_cy
On Fri, 2013-04-12 at 11:20 +0200, Sebastian Hesselbarth wrote:
> With recent support for GRO, there is no need to keep both LRO and
> GRO. This patch therefore removes the deprecated inet_lro support
> from mv643xx_eth. This is work is based on an experimental patch
> provided by Eric
On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote:
> With recent support for GRO, there is no need to keep both LRO and
> GRO. This patch therefore removes the deprecated inet_lro support
> from mv643xx_eth. This is work is based on an experimental patch
> provided by Eric
On Thu, 2013-04-11 at 19:51 +0200, Willy Tarreau wrote:
> Eric provided me with one such experimental patch in the past for this
> driver. It worked for me but we never tried to clean it up to propose
> it for inclusion.
>
> If anyone is interested, I might still have it in experimental shape.
W
On Thu, 2013-04-11 at 13:31 -0400, David Miller wrote:
> I think, as per other drivers, LRO should be eliminated completely from
> all drivers, including this one, and GRO used exclusively instead.
This would be awesome.
AFAIK current LRO users are :
drivers/infiniband/hw/nes/nes_hw.c
drivers/n
On Thu, 2013-04-11 at 18:02 +0200, Willy Tarreau wrote:
> OK, that makes sense indeed, I didn't think about this case. All
> I remember was that the old call achieved a higher packet rate
> than napi_gro_receive, but it was on an older kernel and I can't
> be more specifics after several months :-
>lro_mgr, skb, (void *)cmd_sts);
> lro_flush_needed = 1;
> } else
> - netif_receive_skb(skb);
> + napi_gro_receive(&mp->napi, skb);
>
> continue;
>
Acked-by: Eric Dumazet
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 2013-04-11 at 17:32 +0200, Willy Tarreau wrote:
> On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote:
> > I don't have a strong opinion on whether Soeren's or your proposal should
> > be submitted. But I insist on having one of them in, as GRO significantly
> > improves t
On Thu, 2012-10-18 at 20:55 -0700, Joe Perches wrote:
> ethernet, ipv4, and ipv6 address testing uses 3 different api naming styles.
>
> ethernet uses:is__ether_addr
> ipv4 uses:ipv4_is_
> ipv6 uses:ipv6_addr_
>
> Standardize on the ipv6 style of _addr_ to reduce
> the number of s
On Tue, 2012-10-09 at 10:52 +1100, Michael Neuling wrote:
> The following patch:
> acb600d net: remove skb recycling
> added dev_free_skb() to drivers/net/ethernet/freescale/ucc_geth.c
>
> This is a typo and should be dev_kfree_skb(). This fixes this.
>
> Signed-off-by: Michael Neuling
> ---
On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequential prog
*/
Seems good to me, maybe add a strong warning in the comment to say that
function prototype can NOT change without major surgery in ASM files,
since assembler wont catch the prototype change for us.
Acked-by: Eric Dumazet
___
Linuxppc-dev mailin
Le dimanche 18 mars 2012 à 19:24 -0400, Paul Gortmaker a écrit :
> On Sun, Mar 18, 2012 at 5:55 PM, Eric Dumazet wrote:
> > On Sun, 2012-03-18 at 17:39 -0400, Paul Gortmaker wrote:
> >> The __netif_subqueue_stopped() just does the following:
> >>
> >&
q in scope, we can just call that
> directly in this case.
>
> Suggested-by: Eric Dumazet
> Signed-off-by: Paul Gortmaker
> ---
> drivers/net/ethernet/freescale/gianfar.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/
Le dimanche 18 mars 2012 à 12:56 -0400, Paul Gortmaker a écrit :
> The BQL support here is unchanged from what I posted earlier as an
> RFC[1] -- with the exception of the fact that I'm now happier with
> the runtime testing vs. the simple "hey it boots" that I'd done
> for the RFC. Plus I added a
Le dimanche 18 mars 2012 à 12:56 -0400, Paul Gortmaker a écrit :
...
>* we add this skb back into the pool, if it's the right size
> @@ -2557,13 +2568,15 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q
> *tx_queue)
> }
>
> /* If we freed a buffer, we can rest
gt; arch/powerpc/include/asm/ppc-opcode.h | 40 ++
> arch/powerpc/net/Makefile |4 +
> arch/powerpc/net/bpf_jit.h| 227 +++
> arch/powerpc/net/bpf_jit_64.S | 138 +++
> arch/powerpc/net/bpf_jit_comp.c | 694
> ++
Le mardi 19 juillet 2011 à 17:55 +1000, Benjamin Herrenschmidt a écrit :
> On Tue, 2011-07-19 at 08:51 +0200, Eric Dumazet wrote:
>
> > > + case BPF_S_ANC_CPU:
> > > +#ifdef CONFIG_SMP
> > > + /*
> >
Le mardi 19 juillet 2011 à 12:13 +1000, Matt Evans a écrit :
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackfr
Le lundi 18 juillet 2011 à 12:42 -0700, David Miller a écrit :
> From: Eric Dumazet
> Date: Mon, 18 Jul 2011 10:39:35 +0200
>
> > So in PPC SEEN_XREG only is to be set of X is read, not if written.
> >
> > So you dont have to set SEEN_XREG bit in this part :
>
&g
Le lundi 18 juillet 2011 à 17:50 +1000, Matt Evans a écrit :
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackfr
Le mercredi 13 juillet 2011 à 09:20 +0200, Thomas De Schampheleire a
écrit :
> I just want to mention that, although you seem to think that we
> shouldn't have created this thread in the first place, your and Eric's
> remarks have actually helped us in identifying the problem and
> increasing our
Le mardi 12 juillet 2011 à 14:03 +0200, Ronny Meeus a écrit :
> Sorry for not mentioning we were using a patched kernel.
> I was not aware that the code involved was patched by the FreeScale
> patches we applied. The code found in the stack dumps is not
> implemented in FSL specific files.
>
> Wh
Le mardi 12 juillet 2011 à 11:23 +0200, Thomas De Schampheleire a
écrit :
> Hi,
>
> I'm adding the linuxppc-dev mailing list since this may be pointing to
> an irq/softirq problem in the powerpc architecture-specific code...
>
> Note that the reason we are seeing this problem, may be because the
Le samedi 25 juin 2011 à 09:33 +0200, Andreas Schwab a écrit :
> Matt Evans writes:
>
> > + stdur1, -128(r1); \
>
> > + addir5, r1, 128+BPF_PPC_STACK_BASIC+(2*8); \
>
> > + addir1, r1, 128;\
>
> >
urn ret;
> }
I fully agree with your analysis. This is a call to make the change I
suggested earlier [1]. (Use a seqcount object in seqlock_t)
typedef struct {
seqcount_t seq
spinlock_t lock;
} seqlock_t;
I'll submit a patch for 2.6.40
Acked-by: Eric Dumazet
Thanks
[1] Ref: https://lkml.org/lkml/2011/5/6/351
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Le vendredi 16 juillet 2010 à 11:56 +0200, Eric Dumazet a écrit :
> [PATCH] ehea: ehea_get_stats() should use GFP_KERNEL
>
> ehea_get_stats() is called in process context and should use GFP_KERNEL
> allocation instead of GFP_ATOMIC.
>
> Clearing stats at beginning of ehea_get_
nyway ehea should not use GFP_ATOMIC in its ehea_get_stats() method,
called in process context, but GFP_KERNEL.
Another patch is needed for ehea_refill_rq_def() as well.
[PATCH] ehea: ehea_get_stats() should use GFP_KERNEL
ehea_get_stats() is called in process context and should use GFP_KERNEL
allocat
pc-...@ozlabs.org;
> grant.lik...@secretlab.ca;
> > jwbo...@linux.vnet.ibm.com; john.willi...@petalogix.com;
> michal.si...@petalogix.com; jty...@cs.ucr.edu
> > Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
> >
> > From: Eric Dumazet
> > Da
Le mardi 06 avril 2010 à 12:53 -0600, Grant Likely a écrit :
> Hold on BUFFER_ALIGN is being used to align the DMA buffer on a
> cache line boundary. I don't think netdev_alloc_skb() makes any
> guarantees about how the start of the IP header lines up against cache
> line boundaries. The amo
>
> Yes I see how it's used, but it only allows you to reserve 2 bytes in the skb
> with no options.
Really ? This would be a bug !
__alloc_skb() uses kmalloc(), this gives you the guarantee you want,
or maybe comment you wrote is not what is _really_ necessary ?
/* Align the IP data in
Le mardi 06 avril 2010 à 10:12 -0600, John Linn a écrit :
> > -Original Message-
> > From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> > Sent: Monday, April 05, 2010 3:30 PM
> > To: John Linn
> > Cc: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
Le lundi 05 avril 2010 à 15:11 -0600, John Linn a écrit :
> This patch adds support for using the LL TEMAC Ethernet driver on
> non-Virtex 5 platforms by adding support for accessing the Soft DMA
> registers as if they were memory mapped instead of solely through the
> DCR's (available on the Virte
Le mercredi 17 février 2010 à 15:55 +0100, Anatolij Gustschin a écrit :
> MPC5121 FEC requeries 4-byte alignmnent for TX data buffers.
> This patch is a work around that copies misaligned tx packets
> to an aligned skb before sending.
>
> Signed-off-by: John Rigby
> Signed-off-by: Piotr Ziecik
>
Andi Kleen a écrit :
> Thomas Gleixner writes:
>
>
>> Err, no. Chris is completely correct:
>>
>> if (!in_interrupt())
>> wakeup_softirqd();
>
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It'
Joakim Tjernlund a écrit :
> Also set NAPI weight to 64 as this is a common value.
> This will make the system alot more responsive while
> ping flooding the ucc_geth ethernet interaface.
>
> Signed-off-by: Joakim Tjernlund
> ---
> drivers/net/ucc_geth.c | 32
>
Joakim Tjernlund a écrit :
>>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund
> Date: Tue, 24 Mar 2009 10:19:27 +0100
> Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context.
> Also increase NAPI weight somewhat.
> This will make the
85 matches
Mail list logo
