* Re: [PATCH net-next] i40e: skb->xmit_more support
From: David Miller @ 2014-10-07 20:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dborkman, jeffrey.t.kirsher
In-Reply-To: <1412713823.11091.166.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Oct 2014 13:30:23 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Support skb->xmit_more in i40e is straightforward : we need to move
> around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped()
> before taking the decision to not kick the NIC.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Intel folks, if I could get a quick review of this that would be great.
Thanks.
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: Raghuram Kothakota @ 2014-10-07 20:38 UTC (permalink / raw)
To: David Miller; +Cc: sowmini.varadhan, netdev, david.stevens
In-Reply-To: <20141007.153829.1919460115976279645.davem@davemloft.net>
On Oct 7, 2014, at 12:38 PM, David Miller <davem@davemloft.net> wrote:
> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Date: Tue, 7 Oct 2014 15:29:22 -0400
>
>> I'm not sure how this can be useful to sunvnet- in sunvnet's case
>> we send the TX indication at the *start* of a burst, so if xmit_more
>> was set, sure- we can send out another packet immediately, and
>> avoid another START message (which we already do today), but
>> nothing else to be gained from xmit_more?
>
> If you defer that __vnet_tx_trigger() call through all the ->xmit_more
> SKBs, then you are less likely to see the DRING_STOPPED event from the
> peer which will make you have to send a START again.
>
> So, for an xmit_more burst of 3, instead of:
>
> ->ndo_start_xmit()
> __vnet_tx_trigger()
> ->ndo_start_xmit()
> IRQ -> vnet_ack() -> STOPPED
> ->ndo_start_xmit()
> __vnet_tx_trigger()
>
> You would do something like:
>
> ->ndo_start_xmit()
> ->ndo_start_xmit()
> ->ndo_start_xmit()
> __vnet_tx_trigger()
In case of sunvnet, consumer starting as soon as possible would help
as the consumer is slower as it copies the data to local buffers. The recent
change by DLS avoids the copy in the Tx side, so the producer could be
faster than the receiver. If the trigger is sent after n packets, then consumer
will really start after n packets in the ring and it may have lost that much time
to pickup the packets.
-Raghuram
>
>> BTW, I have most of the NAPI done, getting it stress-tested etc
>> (the recent jumbo commit added a few more races between vnet_port_remove
>> and vnet_start_xmit, thanks to the extra clean_timer) but I figure
>> I might as well fully test this internally since net-next is closed
>> for the moment anyway?
>
> Yeah no rush.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Alexei Starovoitov @ 2014-10-07 20:43 UTC (permalink / raw)
To: David Miller
Cc: Tom Herbert, Jesse Gross, gerlitz.or@gmail.com, Alexander Duyck,
John Fastabend, Jeff Kirsher, netdev@vger.kernel.org, Thomas Graf,
Pravin Shelar, Andy Zhou
In-Reply-To: <20141007.163239.157997964784151921.davem@davemloft.net>
On Tue, Oct 7, 2014 at 1:32 PM, David Miller <davem@davemloft.net> wrote:
> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Date: Tue, 7 Oct 2014 13:28:01 -0700
>
>> On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>>>
>>> I am totally against boolean "yes/no" protocol specific checksum
>>> validation by HW.
>>>
>>> It's not faster. You have to look at the pseudo-header and bring it into
>>> the CPU cache _anyways_, so negating it and 2's complementing it into
>>> the CHECKSUM_COMPLETE value for validation is free.
>>>
>>> There is no performance advantage whatsoever to use another checksumming
>>> scheme.
>>
>> ok, forget faster/slower argument for a second.
>> Why is it a bad thing to have HW verifying checksums?
>
> Because you have to change the damn hardware and/or firmware for every
> new protocol.
It is true for existing NICs, but it is not true for upcoming devices.
They're exposing packet parsers to users, so we will be able to
program any protocol into the device without reflashing it.
Some of the guys are even allowing reprogramming the parser
while packets are flowing.
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: David Miller @ 2014-10-07 20:46 UTC (permalink / raw)
To: Raghuram.Kothakota; +Cc: sowmini.varadhan, netdev, david.stevens
In-Reply-To: <9BB04EDE-1842-4DB0-93BE-5186B2D187AB@oracle.com>
From: Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Date: Tue, 7 Oct 2014 13:38:07 -0700
> In case of sunvnet, consumer starting as soon as possible would help
> as the consumer is slower as it copies the data to local buffers. The recent
> change by DLS avoids the copy in the Tx side, so the producer could be
> faster than the receiver. If the trigger is sent after n packets, then consumer
> will really start after n packets in the ring and it may have lost that much time
> to pickup the packets.
I agree for the first few TX queue entires, or even just the first, but after
that it always pays to defer and decrease the number of hcalls, locks, etc.
Play with it, you'll see.
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: David Miller @ 2014-10-07 20:48 UTC (permalink / raw)
To: alexei.starovoitov
Cc: therbert, jesse, gerlitz.or, alexander.h.duyck, john.r.fastabend,
jeffrey.t.kirsher, netdev, tgraf, pshelar, azhou
In-Reply-To: <CAADnVQJDxPsMeuNmnR5iUwccOKG2A02dZ+3Ae6wGg-RNFPeeeQ@mail.gmail.com>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Tue, 7 Oct 2014 13:43:09 -0700
> On Tue, Oct 7, 2014 at 1:32 PM, David Miller <davem@davemloft.net> wrote:
>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Date: Tue, 7 Oct 2014 13:28:01 -0700
>>
>>> On Tue, Oct 7, 2014 at 11:47 AM, David Miller <davem@davemloft.net> wrote:
>>>>
>>>> I am totally against boolean "yes/no" protocol specific checksum
>>>> validation by HW.
>>>>
>>>> It's not faster. You have to look at the pseudo-header and bring it into
>>>> the CPU cache _anyways_, so negating it and 2's complementing it into
>>>> the CHECKSUM_COMPLETE value for validation is free.
>>>>
>>>> There is no performance advantage whatsoever to use another checksumming
>>>> scheme.
>>>
>>> ok, forget faster/slower argument for a second.
>>> Why is it a bad thing to have HW verifying checksums?
>>
>> Because you have to change the damn hardware and/or firmware for every
>> new protocol.
>
> It is true for existing NICs, but it is not true for upcoming devices.
> They're exposing packet parsers to users, so we will be able to
> program any protocol into the device without reflashing it.
> Some of the guys are even allowing reprogramming the parser
> while packets are flowing.
So we have to write new software in _EVERY_ driver to accomodate this.
That makes zero sense either, and it is unneeded complexity in the
hardware.
COMPLETE works everywhere, on everything, with no driver changes, and
is so much harder to get wrong.
Every protocol specific feature has major downsides whether you choose
to see them or not.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Fabian Frederick @ 2014-10-07 20:49 UTC (permalink / raw)
To: Guenter Roeck, David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20141007203344.GA4748@roeck-us.net>
> On 07 October 2014 at 22:33 Guenter Roeck <linux@roeck-us.net> wrote:
>
>
> On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> > From: Fabian Frederick <fabf@skynet.be>
> > Date: Tue, 7 Oct 2014 22:16:36 +0200
> >
> > > static values are automatically initialized to NULL
> > >
> > > Signed-off-by: Fabian Frederick <fabf@skynet.be>
> >
> > Isn't there some implementation room given to compilers
> > as to the representation of true and false?
>
> Not for true/false.
>
> C99 standard, section 7.16:
>
> ...
> The remaining three macros are suitable for use in #if preprocessing
> directives. They are
>
> true
>
> which expands to the integer constant 1,
>
> false
>
> which expands to the integer constant 0, and
> ...
>
> No idea where the NULL comes into the picture, though.
>
> Guenter
Maybe comment should have been "static values are automatically initialized to
0" then ?
Regards,
Fabian
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: David Miller @ 2014-10-07 20:50 UTC (permalink / raw)
To: fabf; +Cc: linux, netdev, linux-kernel
In-Reply-To: <1559212122.19553.1412714971908.open-xchange@webmail.nmp.skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 22:49:31 +0200 (CEST)
> Maybe comment should have been "static values are automatically initialized to
> 0" then ?
Yes, that sounds a lot better, please respin.
^ permalink raw reply
* Re: sunvnet and ->xmit_more
From: Sowmini Varadhan @ 2014-10-07 20:51 UTC (permalink / raw)
To: David Miller; +Cc: Raghuram.Kothakota, netdev, david.stevens
In-Reply-To: <20141007.164649.587971614591244924.davem@davemloft.net>
On (10/07/14 16:46), David Miller wrote:
>
> Play with it, you'll see.
at the moment, there are enough fun and games just doing a
"modload -r sunvnet; modload sunvnet" in a loop while running iperf.
I think running stably is as important as tput, no? :-) Lets fix
all the races first.
--Sowmini
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Hannes Frederic Sowa @ 2014-10-07 20:54 UTC (permalink / raw)
To: Fabian Frederick; +Cc: Guenter Roeck, David Miller, netdev, linux-kernel
In-Reply-To: <1559212122.19553.1412714971908.open-xchange@webmail.nmp.skynet.be>
On Di, 2014-10-07 at 22:49 +0200, Fabian Frederick wrote:
>
> > On 07 October 2014 at 22:33 Guenter Roeck <linux@roeck-us.net> wrote:
> >
> >
> > On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> > > From: Fabian Frederick <fabf@skynet.be>
> > > Date: Tue, 7 Oct 2014 22:16:36 +0200
> > >
> > > > static values are automatically initialized to NULL
> > > >
> > > > Signed-off-by: Fabian Frederick <fabf@skynet.be>
> > >
> > > Isn't there some implementation room given to compilers
> > > as to the representation of true and false?
> >
> > Not for true/false.
> >
> > C99 standard, section 7.16:
> >
> > ...
> > The remaining three macros are suitable for use in #if preprocessing
> > directives. They are
> >
> > true
> >
> > which expands to the integer constant 1,
> >
> > false
> >
> > which expands to the integer constant 0, and
> > ...
> >
> > No idea where the NULL comes into the picture, though.
> >
> > Guenter
>
> Maybe comment should have been "static values are automatically initialized to
> 0" then ?
I think David's concern was whether if 0 == false in all situations. It
is pretty clear that static memory is initialized to 0.
Thanks,
Hannes
^ permalink raw reply
* [PATCH V2 net-next] af_unix: remove 0 assignment on static
From: Fabian Frederick @ 2014-10-07 21:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Fabian Frederick, David S. Miller, netdev
static values are automatically initialized to 0
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
V2: replace NULL by 0 in description
net/unix/garbage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index 9bc73f8..99f7012 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -258,7 +258,7 @@ static void inc_inflight_move_tail(struct unix_sock *u)
list_move_tail(&u->link, &gc_candidates);
}
-static bool gc_in_progress = false;
+static bool gc_in_progress;
#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
--
1.9.3
^ permalink raw reply related
* Re: [PATCH V2 net-next] af_unix: remove 0 assignment on static
From: David Miller @ 2014-10-07 21:03 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1412715735-6757-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 23:02:15 +0200
> static values are automatically initialized to 0
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> V2: replace NULL by 0 in description
Applied, thanks Fabian.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] af_unix: remove NULL assignment on static
From: Fabian Frederick @ 2014-10-07 21:05 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, linux-kernel, Guenter Roeck, David Miller
In-Reply-To: <1412715283.11600.11.camel@localhost>
> On 07 October 2014 at 22:54 Hannes Frederic Sowa <hannes@stressinduktion.org>
> wrote:
>
>
> On Di, 2014-10-07 at 22:49 +0200, Fabian Frederick wrote:
> >
> > > On 07 October 2014 at 22:33 Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > >
> > > On Tue, Oct 07, 2014 at 04:18:32PM -0400, David Miller wrote:
> > > > From: Fabian Frederick <fabf@skynet.be>
> > > > Date: Tue, 7 Oct 2014 22:16:36 +0200
> > > >
> > > > > static values are automatically initialized to NULL
> > > > >
> > > > > Signed-off-by: Fabian Frederick <fabf@skynet.be>
> > > >
> > > > Isn't there some implementation room given to compilers
> > > > as to the representation of true and false?
> > >
> > > Not for true/false.
> > >
> > > C99 standard, section 7.16:
> > >
> > > ...
> > > The remaining three macros are suitable for use in #if preprocessing
> > > directives. They are
> > >
> > > true
> > >
> > > which expands to the integer constant 1,
> > >
> > > false
> > >
> > > which expands to the integer constant 0, and
> > > ...
> > >
> > > No idea where the NULL comes into the picture, though.
> > >
> > > Guenter
> >
> > Maybe comment should have been "static values are automatically initialized
> > to
> > 0" then ?
>
> I think David's concern was whether if 0 == false in all situations. It
> is pretty clear that static memory is initialized to 0.
>
> Thanks,
> Hannes
Of course :) It was an answer to Guenter's explanation.
Regards,
Fabian
>
>
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Thomas Graf @ 2014-10-07 21:41 UTC (permalink / raw)
To: David Miller
Cc: alexei.starovoitov, therbert, jesse, gerlitz.or,
alexander.h.duyck, john.r.fastabend, jeffrey.t.kirsher, netdev,
pshelar, azhou
In-Reply-To: <20141007.164802.624713385845633192.davem@davemloft.net>
On 10/07/14 at 04:48pm, David Miller wrote:
> So we have to write new software in _EVERY_ driver to accomodate this.
>
> That makes zero sense either, and it is unneeded complexity in the
> hardware.
>
> COMPLETE works everywhere, on everything, with no driver changes, and
> is so much harder to get wrong.
>
> Every protocol specific feature has major downsides whether you choose
> to see them or not.
It's probably not overly bold to state that the behaviour behind
CHECKSUM_UNNECESSARY was not created for technical reasons in the
first place.
I enourage NICs to have protocol awareness in the absence of full
programmability but I agree with Dave that there is little to no
reason to expose anything but the full packet checksum to the CPU.
^ permalink raw reply
* Re: [PATCH net-next] i40e: skb->xmit_more support
From: Daniel Borkmann @ 2014-10-07 22:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Jeff Kirsher
In-Reply-To: <1412713823.11091.166.camel@edumazet-glaptop2.roam.corp.google.com>
On 10/07/2014 10:30 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Support skb->xmit_more in i40e is straightforward : we need to move
> around i40e_maybe_stop_tx() call to correctly test netif_xmit_stopped()
> before taking the decision to not kick the NIC.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Jeff, feel free to drop the same version I've sent you yesterday
directly since this here is already in patchwork ...
Thanks, Eric!
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Alexei Starovoitov @ 2014-10-07 22:05 UTC (permalink / raw)
To: David Miller
Cc: Tom Herbert, Jesse Gross, gerlitz.or@gmail.com, Alexander Duyck,
John Fastabend, Jeff Kirsher, netdev@vger.kernel.org, Thomas Graf,
Pravin Shelar, Andy Zhou
On Tue, Oct 7, 2014 at 1:48 PM, David Miller <davem@davemloft.net> wrote:
>> They're exposing packet parsers to users, so we will be able to
>> program any protocol into the device without reflashing it.
>> Some of the guys are even allowing reprogramming the parser
>> while packets are flowing.
>
> So we have to write new software in _EVERY_ driver to accomodate this.
>
> That makes zero sense either, and it is unneeded complexity in the
> hardware.
I have to agree that for single purpose of csum verify
adding all the complexity around programmable
parsers doesn't make sense.
To me packet parsing is the first step of HW offload,
regardless whether it's flow based or what else this hw can do.
I'd rather see HW vendors provide programmable parser
for any and all protocols instead of them saying:
here is my device X that supports protocols defined
by standards Y and Z.
(which is the case today and it's not pretty)
> COMPLETE works everywhere, on everything, with no driver changes, and
> is so much harder to get wrong.
agree. I'm not against COMPLETE in any way.
> Every protocol specific feature has major downsides whether you choose
> to see them or not.
I surely don't have a preference to a protocol.
I want to see programmable HW that supports any crazy
packet format.
Let's get back to COMPLETE and VMs example,
because I want to see it fixed.
In such case kernel stack in hypervisor will be pulling
encap headers then populating new field in virtio
ring with updated csum and let guest VMs to continue
adjusting that csum, right?
Alternative would be to do inner processing and
csum verification in hypervisor so that packet
can be marked as DATA_VALID, but is it better?
^ permalink raw reply
* Re: [PATCH 1/1 net-next] netlabel: kernel-doc warning fix
From: Paul Moore @ 2014-10-07 22:13 UTC (permalink / raw)
To: Fabian Frederick, David S. Miller; +Cc: linux-kernel, netdev
In-Reply-To: <1412713892-5537-1-git-send-email-fabf@skynet.be>
On Tuesday, October 07, 2014 10:31:32 PM Fabian Frederick wrote:
> no secid argument in netlbl_cfg_unlbl_static_del
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Thanks. Likely a copy/paste error from netlbl_cfg_unlbl_static_add().
Acked-by: Paul Moore <paul@paul-moore.com>
> ---
> net/netlabel/netlabel_kapi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 0b4692d..a845cd4 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -246,7 +246,6 @@ int netlbl_cfg_unlbl_static_add(struct net *net,
> * @addr: IP address in network byte order (struct in[6]_addr)
> * @mask: address mask in network byte order (struct in[6]_addr)
> * @family: address family
> - * @secid: LSM secid value for the entry
> * @audit_info: NetLabel audit information
> *
> * Description:
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Tom Herbert @ 2014-10-07 23:43 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Miller, Jesse Gross, gerlitz.or@gmail.com, Alexander Duyck,
John Fastabend, Jeff Kirsher, netdev@vger.kernel.org, Thomas Graf,
Pravin Shelar, Andy Zhou
In-Reply-To: <CAADnVQ+wRjo3ORK5_Ra4c9W5bgyFBgotbeGB1fAuPkz1a=oy7g@mail.gmail.com>
On Tue, Oct 7, 2014 at 3:05 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Tue, Oct 7, 2014 at 1:48 PM, David Miller <davem@davemloft.net> wrote:
>>> They're exposing packet parsers to users, so we will be able to
>>> program any protocol into the device without reflashing it.
>>> Some of the guys are even allowing reprogramming the parser
>>> while packets are flowing.
>>
>> So we have to write new software in _EVERY_ driver to accomodate this.
>>
>> That makes zero sense either, and it is unneeded complexity in the
>> hardware.
>
> I have to agree that for single purpose of csum verify
> adding all the complexity around programmable
> parsers doesn't make sense.
> To me packet parsing is the first step of HW offload,
> regardless whether it's flow based or what else this hw can do.
>
> I'd rather see HW vendors provide programmable parser
> for any and all protocols instead of them saying:
> here is my device X that supports protocols defined
> by standards Y and Z.
> (which is the case today and it's not pretty)
>
>> COMPLETE works everywhere, on everything, with no driver changes, and
>> is so much harder to get wrong.
>
> agree. I'm not against COMPLETE in any way.
>
>> Every protocol specific feature has major downsides whether you choose
>> to see them or not.
>
> I surely don't have a preference to a protocol.
> I want to see programmable HW that supports any crazy
> packet format.
>
> Let's get back to COMPLETE and VMs example,
> because I want to see it fixed.
> In such case kernel stack in hypervisor will be pulling
> encap headers then populating new field in virtio
> ring with updated csum and let guest VMs to continue
> adjusting that csum, right?
That seems like the correct approach. It's not even guaranteed that
the kernel or device could parse the inner packet to verify inner
checksums (consider if checksum was added to a protocol like QUIC).
> Alternative would be to do inner processing and
> csum verification in hypervisor so that packet
> can be marked as DATA_VALID, but is it better?
One important clarification in RX checksum overhaul is that
CHECKSUM_UNNECESSARY does not mean that all possible checksums in the
packet have been verified. It means that one or more (per csum_level)
consecutive checksums have been verified. Seems like the DATA_VALID
interface might need a similar clarification.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] wimax: convert printk to pr_foo()
From: David Miller @ 2014-10-08 0:27 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, inaky.perez-gonzalez, linux-wimax, netdev
In-Reply-To: <1412712724-4100-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Tue, 7 Oct 2014 22:12:03 +0200
> Use current logging functions and add module name prefix.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1 net-next] netlabel: kernel-doc warning fix
From: David Miller @ 2014-10-08 0:30 UTC (permalink / raw)
To: paul; +Cc: fabf, linux-kernel, netdev
In-Reply-To: <18856194.K9PbrNbEaI@sifl>
From: Paul Moore <paul@paul-moore.com>
Date: Tue, 07 Oct 2014 18:13:34 -0400
> On Tuesday, October 07, 2014 10:31:32 PM Fabian Frederick wrote:
>> no secid argument in netlbl_cfg_unlbl_static_del
>>
>> Signed-off-by: Fabian Frederick <fabf@skynet.be>
>
> Thanks. Likely a copy/paste error from netlbl_cfg_unlbl_static_add().
>
> Acked-by: Paul Moore <paul@paul-moore.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Wheeler @ 2014-10-08 0:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <1412651746.11091.98.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, 6 Oct 2014, Eric Dumazet wrote:
> On Mon, 2014-10-06 at 20:05 -0700, Eric Wheeler wrote:
>> On Mon, 6 Oct 2014, Eric Dumazet wrote:
>>> On Mon, 2014-10-06 at 18:57 -0700, Eric Wheeler wrote:
>>>> This patch fixes an order:2 memory allocation error backtrace by
>>>> guaranteeing that memory is available during simultaneous high memory
>>>> pressure and packet rates when using 9k jumbo frames.
>>>
>>> This is highly suspect to me.
>>> Most likely yet another truesize lie.
>>> At a first glance, bnad_cq_setup_skb_frags() is buggy here :
>>> skb->truesize += totlen;
>
> It seems many drivers make this assumption that a frame of 1000 bytes
> consumes 1000 bytes of memory.
>
> Reality is that driver allocated more memory, because it can not predict
> how many bytes are going to be received from the network.
>
> By lying on skb->truesize (underestimating real memory cost), this
> prevents networking stack making appropriate memory checks.
>
> Here, it seems clear to me the following fix is needed, at very minimum.
>
> And it might be that something better is needed : MTU=9000 might force
> the driver to allocate 16384 bytes per frame, not 9018
>
> So it is possible that unmap->vector.len needs to be changed to the real
> size of memory region (for example : PAGE_SIZE << 2)
Just += unmap->vector.len still did not work (same backtrace), so I've
rebuilt with PAGE_SIZE<<2 and so far so good. I'll let it run all night
and see if we get any problems.
-Eric
--
Eric Wheeler, President eWheeler, Inc. dba Global Linux Security
888-LINUX26 (888-546-8926) Fax: 503-716-3878 PO Box 25107
www.GlobalLinuxSecurity.pro Linux since 1996! Portland, OR 97298
>
>
> diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
> index ffc92a41d75be550d27698af6ca3e600d9a146fe..ce867219e2ceaf33b17595b67bae99e964d5a6b6 100644
> --- a/drivers/net/ethernet/brocade/bna/bnad.c
> +++ b/drivers/net/ethernet/brocade/bna/bnad.c
> @@ -550,6 +550,7 @@ bnad_cq_setup_skb_frags(struct bna_rcb *rcb, struct sk_buff *skb,
> dma_unmap_addr(&unmap->vector, dma_addr),
> unmap->vector.len, DMA_FROM_DEVICE);
>
> + skb->truesize += unmap->vector.len;
> len = (vec == nvecs) ?
> last_fraglen : unmap->vector.len;
> totlen += len;
> @@ -563,7 +564,6 @@ bnad_cq_setup_skb_frags(struct bna_rcb *rcb, struct sk_buff *skb,
>
> skb->len += totlen;
> skb->data_len += totlen;
> - skb->truesize += totlen;
> }
>
> static inline void
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [net v2 0/8] gianfar: ARM port driver updates (1/2)
From: David Miller @ 2014-10-08 0:35 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, Li.Xiubo, Shruti, kim.phillips
In-Reply-To: <1412667875-18225-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Tue, 7 Oct 2014 10:44:27 +0300
> This is the first round of driver portability fixes and clean-up
> with the main purpose to make gianfar portable on ARM, for the ARM
> based SoC that integrates the eTSEC ethernet controller - "ls1021a".
> The patches primarily address compile time errors, when compiling
> gianfar on ARM. They replace PPC specific functions and macros
> with architecture independent ones, solve arch specific header
> inclusions, guard code that relates to PPC only, and even address
> some simple endianess issues (see MAC address setup patch).
> The patches addressing the bulk of remaining endianess issues,
> like handling DMA fields (BD and FCB), will follow with the second
> round.
>
> Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Series applied, thanks.
^ permalink raw reply
* [PATCH/RFC] datapath: offload hooks
From: Simon Horman @ 2014-10-08 0:40 UTC (permalink / raw)
To: dev, netdev
Cc: Pravin Shelar, Jesse Gross, Jiri Pirko, Thomas Graf,
John Fastabend, Scott Feldman, Roopa Prabhu, Alexi Starovoitov,
Florian Fainelli, Jamal Hadi Salim, Bert van Leeuwen,
Simon Horman
From: Bert van Leeuwen <bert.vanleeuwen@netronome.com>
Hi,
the purpose of posting this patch is to further the ongoing discussion
on hardware offloads for Open vSwitch. It reflects work at Netronome to
provide such offloads. The intention is for this work to be generic.
There is an accompanying document to this patch which attempts to
describe the problem-space the hooks operate in. The document
is intended to be fairly generic and high level. It is intended
to be a point for ongoing discussion and as such comments via
the Google-docs interface are welcome. It is not intended to be
Netronome specific.
https://docs.google.com/a/netronome.com/document/d/1UtG3xY0xMzIwMG732gaypyR6vxGxinkRrnMLnVS4Zao/edit#
The document at the URL above is indented to supplement the Open vSwitch
Hardware Offload Architecture document, which I believe is collated by
Thomas Graf.
https://docs.google.com/document/d/195waUliu7G5YYVuXHmLmHgJ38DFSte321WPq0oaFhyU/edit#
This patch is the collective work by a number of engineers at Netronome.
Co-authored-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Signed-off-by: Bert van Leeuwen <bert.vanleeuwen@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
datapath/Modules.mk | 2 +
datapath/datapath.c | 22 ++++++
datapath/datapath.h | 4 +
datapath/flow.h | 1 +
datapath/linux/.gitignore | 1 +
datapath/offload_ops.c | 49 ++++++++++++
datapath/offload_ops.h | 184 ++++++++++++++++++++++++++++++++++++++++++++++
datapath/vport.h | 3 +
8 files changed, 266 insertions(+)
create mode 100644 datapath/offload_ops.c
create mode 100644 datapath/offload_ops.h
diff --git a/datapath/Modules.mk b/datapath/Modules.mk
index 90e158c..3286621 100644
--- a/datapath/Modules.mk
+++ b/datapath/Modules.mk
@@ -7,6 +7,7 @@ build_modules = $(both_modules) # Modules to build
dist_modules = $(both_modules) # Modules to distribute
openvswitch_sources = \
+ offload_ops.c \
actions.c \
datapath.c \
dp_notify.c \
@@ -22,6 +23,7 @@ openvswitch_sources = \
vport-vxlan.c
openvswitch_headers = \
+ offload_ops.h \
compat.h \
datapath.h \
flow.h \
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 3ca9716..b598f48 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -61,6 +61,7 @@
#include "vlan.h"
#include "vport-internal_dev.h"
#include "vport-netdev.h"
+#include "offload_ops.h"
int ovs_net_id __read_mostly;
@@ -651,6 +652,7 @@ static void get_dp_stats(struct datapath *dp, struct ovs_dp_stats *stats,
stats->n_lost += local_stats.n_lost;
mega_stats->n_mask_hit += local_stats.n_mask_hit;
}
+ ovs_offload_dp_stats_get(dp, stats);
}
static size_t ovs_flow_cmd_msg_size(const struct sw_flow_actions *acts)
@@ -705,6 +707,7 @@ static int ovs_flow_cmd_fill_stats(const struct sw_flow *flow,
unsigned long used;
ovs_flow_stats_get(flow, &stats, &used, &tcp_flags);
+ ovs_offload_flow_stats_get(flow, &stats, &used, &tcp_flags);
if (used &&
nla_put_u64(skb, OVS_FLOW_ATTR_USED, ovs_flow_used_time(used)))
@@ -906,6 +909,7 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
acts = NULL;
goto err_unlock_ovs;
}
+ ovs_offload_flow_new(new_flow);
if (unlikely(reply)) {
error = ovs_flow_cmd_fill_info(dp, new_flow,
@@ -1059,6 +1063,7 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, struct genl_info *info)
OVS_FLOW_CMD_NEW);
BUG_ON(error < 0);
}
+ ovs_offload_flow_set(flow);
} else {
/* Could not alloc without acts before locking. */
reply = ovs_flow_cmd_build_info(dp, flow,
@@ -1073,6 +1078,7 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, struct genl_info *info)
/* Clear stats. */
if (a[OVS_FLOW_ATTR_CLEAR])
ovs_flow_stats_clear(flow);
+ ovs_offload_flow_stats_clear(flow);
ovs_unlock();
if (reply)
@@ -1172,6 +1178,7 @@ static int ovs_flow_cmd_del(struct sk_buff *skb, struct genl_info *info)
goto unlock;
}
+ ovs_offload_flow_del(flow);
ovs_flow_tbl_remove(&dp->table, flow);
ovs_unlock();
@@ -1461,6 +1468,7 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
goto err_destroy_ports_array;
}
+ ovs_offload_dp_new(dp);
err = ovs_dp_cmd_fill_info(dp, reply, info->snd_portid,
info->snd_seq, 0, OVS_DP_CMD_NEW);
BUG_ON(err < 0);
@@ -1530,6 +1538,7 @@ static int ovs_dp_cmd_del(struct sk_buff *skb, struct genl_info *info)
if (IS_ERR(dp))
goto err_unlock_free;
+ ovs_offload_dp_del(dp);
err = ovs_dp_cmd_fill_info(dp, reply, info->snd_portid,
info->snd_seq, 0, OVS_DP_CMD_DEL);
BUG_ON(err < 0);
@@ -1563,6 +1572,7 @@ static int ovs_dp_cmd_set(struct sk_buff *skb, struct genl_info *info)
goto err_unlock_free;
ovs_dp_change(dp, info->attrs);
+ ovs_offload_dp_set(dp);
err = ovs_dp_cmd_fill_info(dp, reply, info->snd_portid,
info->snd_seq, 0, OVS_DP_CMD_NEW);
@@ -1695,6 +1705,7 @@ static int ovs_vport_cmd_fill_info(struct vport *vport, struct sk_buff *skb,
goto nla_put_failure;
ovs_vport_get_stats(vport, &vport_stats);
+ ovs_offload_vport_stats_get(vport, &vport_stats);
if (nla_put(skb, OVS_VPORT_ATTR_STATS, sizeof(struct ovs_vport_stats),
&vport_stats))
goto nla_put_failure;
@@ -1833,10 +1844,14 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
err = 0;
if (a[OVS_VPORT_ATTR_STATS])
ovs_vport_set_stats(vport, nla_data(a[OVS_VPORT_ATTR_STATS]));
+ ovs_offload_vport_stats_set(vport,
+ nla_data(a[OVS_VPORT_ATTR_STATS]));
+
err = ovs_vport_cmd_fill_info(vport, reply, info->snd_portid,
info->snd_seq, 0, OVS_VPORT_CMD_NEW);
BUG_ON(err < 0);
+ ovs_offload_vport_new(skb, vport, &parms);
ovs_unlock();
ovs_notify(&dp_vport_genl_family, &ovs_dp_vport_multicast_group, reply, info);
@@ -1891,6 +1906,7 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
err = ovs_vport_cmd_fill_info(vport, reply, info->snd_portid,
info->snd_seq, 0, OVS_VPORT_CMD_NEW);
BUG_ON(err < 0);
+ ovs_offload_vport_set(skb, vport);
ovs_unlock();
ovs_notify(&dp_vport_genl_family, &ovs_dp_vport_multicast_group, reply, info);
@@ -1928,6 +1944,7 @@ static int ovs_vport_cmd_del(struct sk_buff *skb, struct genl_info *info)
info->snd_seq, 0, OVS_VPORT_CMD_DEL);
BUG_ON(err < 0);
ovs_dp_detach_port(vport);
+ ovs_offload_vport_del(skb, vport);
ovs_unlock();
ovs_notify(&dp_vport_genl_family, &ovs_dp_vport_multicast_group, reply, info);
@@ -2149,6 +2166,10 @@ static int __init dp_init(void)
if (err < 0)
goto error_unreg_notifier;
+ err = ovs_offload_init_handler();
+ if (err)
+ goto error;
+
return 0;
error_unreg_notifier:
@@ -2165,6 +2186,7 @@ error:
static void dp_cleanup(void)
{
+ ovs_offload_cleanup_handler();
dp_unregister_genl(ARRAY_SIZE(dp_genl_families));
unregister_netdevice_notifier(&ovs_dp_device_notifier);
unregister_pernet_device(&ovs_net_ops);
diff --git a/datapath/datapath.h b/datapath/datapath.h
index 651c119..fc54169 100644
--- a/datapath/datapath.h
+++ b/datapath/datapath.h
@@ -68,6 +68,7 @@ struct dp_stats_percpu {
* @ports: Hash table for ports. %OVSP_LOCAL port always exists. Protected by
* ovs_mutex and RCU.
* @stats_percpu: Per-CPU datapath statistics.
+ * @offload: Hardware offload callbacks
* @net: Reference to net namespace.
*
* Context: See the comment on locking at the top of datapath.c for additional
@@ -86,6 +87,9 @@ struct datapath {
/* Stats. */
struct dp_stats_percpu __percpu *stats_percpu;
+ /* Hardware offload ptr. */
+ void *offload;
+
#ifdef CONFIG_NET_NS
/* Network namespace ref. */
struct net *net;
diff --git a/datapath/flow.h b/datapath/flow.h
index 44ed10d..e50988c 100644
--- a/datapath/flow.h
+++ b/datapath/flow.h
@@ -220,6 +220,7 @@ struct sw_flow {
int stats_last_writer; /* NUMA-node id of the last writer on
* 'stats[0]'.
*/
+ void *offload;
struct sw_flow_key key;
struct sw_flow_key unmasked_key;
struct sw_flow_mask *mask;
diff --git a/datapath/linux/.gitignore b/datapath/linux/.gitignore
index be233fc..0ce4663 100644
--- a/datapath/linux/.gitignore
+++ b/datapath/linux/.gitignore
@@ -51,3 +51,4 @@
/vport.c
/vxlan.c
/workqueue.c
+/offload_ops.c
diff --git a/datapath/offload_ops.c b/datapath/offload_ops.c
new file mode 100644
index 0000000..2eda940
--- /dev/null
+++ b/datapath/offload_ops.c
@@ -0,0 +1,49 @@
+#include "offload_ops.h"
+
+struct ovs_offload_ops *offload_ops;
+
+int ovs_offload_register(const struct ovs_offload_ops *new_handler)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload)
+ return -EBUSY;
+ offload = kmalloc(sizeof(*offload), GFP_KERNEL);
+ if (!offload)
+ return -ENOMEM;
+ *offload = *new_handler;
+
+ rcu_assign_pointer(offload_ops, offload);
+ return 0;
+}
+
+EXPORT_SYMBOL(ovs_offload_register);
+
+int ovs_offload_unregister()
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload) {
+ rcu_assign_pointer(offload_ops, NULL);
+ kfree(offload);
+ }
+ return 0;
+}
+
+EXPORT_SYMBOL(ovs_offload_unregister);
+
+int ovs_offload_init_handler(void)
+{
+ rcu_assign_pointer(offload_ops, NULL);
+ return 0;
+}
+
+void ovs_offload_cleanup_handler(void)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload)
+ kfree(offload);
+ rcu_assign_pointer(offload_ops, NULL);
+}
+
diff --git a/datapath/offload_ops.h b/datapath/offload_ops.h
new file mode 100644
index 0000000..9783ba4
--- /dev/null
+++ b/datapath/offload_ops.h
@@ -0,0 +1,184 @@
+#ifndef _OFFLOAD_OPS_H
+#define _OFFLOAD_OPS_H
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+
+#include "datapath.h"
+#include "flow.h"
+
+struct ovs_offload_ops {
+ /* Flow offload functions */
+ /* Called when a flow entry is added to the flow table */
+ void (*flow_new)(struct sw_flow *);
+ /* Called when a flow entry is modified */
+ void (*flow_set)(struct sw_flow *);
+ /* Called when a flow entry is removed from the flow table */
+ void (*flow_del)(struct sw_flow *);
+ /* Called when flow stats are queried */
+ void (*flow_stats_get)(const struct sw_flow *, struct ovs_flow_stats *,
+ unsigned long *used, __be16 *tcp_flags);
+ /* Called when flow stats are removed */
+ void (*flow_stats_clear)(struct sw_flow *);
+
+ /* Port offload functions */
+ /* Called when a vport is added to the datapath */
+ void (*vport_new)(struct sk_buff *, struct vport *,
+ struct vport_parms *);
+ /* Called when a vport is modified */
+ void (*vport_set)(struct sk_buff *, struct vport *);
+ /* Called when a vport is removed from the datapath */
+ void (*vport_del)(struct sk_buff *, struct vport *);
+ /* Called when vport stats are queried */
+ void (*vport_stats_get)(struct vport *, struct ovs_vport_stats *);
+ /* Called when vport stats are set */
+ void (*vport_stats_set)(struct vport *, struct ovs_vport_stats *);
+
+ /* Datapath offload functions */
+ /* Called when the datapath is created */
+ void (*dp_new)(struct datapath *);
+ /* Called when the datapath is modified */
+ void (*dp_set)(struct datapath *);
+ /* Called when the datapath is removed */
+ void (*dp_del)(struct datapath *);
+ /* Called when the datapath stats are queried */
+ void (*dp_stats_get)(struct datapath *, struct ovs_dp_stats *);
+};
+
+extern struct ovs_offload_ops *offload_ops;
+
+int ovs_offload_register(const struct ovs_offload_ops *new_handler);
+int ovs_offload_unregister(void);
+int ovs_offload_init_handler(void);
+void ovs_offload_cleanup_handler(void);
+
+/* Wrappers for calling offload function with locking in place */
+/* Flow offload functions */
+static inline void ovs_offload_flow_new(struct sw_flow *flow)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->flow_new)
+ offload->flow_new(flow);
+}
+
+static inline void ovs_offload_flow_set(struct sw_flow *flow)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->flow_set)
+ offload->flow_set(flow);
+}
+
+static inline void ovs_offload_flow_del(struct sw_flow *flow)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->flow_del)
+ offload->flow_del(flow);
+}
+
+static inline void ovs_offload_flow_stats_get(const struct sw_flow *flow,
+ struct ovs_flow_stats *stats,
+ unsigned long *used,
+ __be16 *tcp_flags)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->flow_stats_get)
+ offload->flow_stats_get(flow, stats, used, tcp_flags);
+}
+
+static inline void ovs_offload_flow_stats_clear(struct sw_flow *flow)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->flow_stats_clear)
+ offload->flow_stats_clear(flow);
+}
+
+/* Port offload functions */
+static inline void ovs_offload_vport_new(struct sk_buff *skb,
+ struct vport *vport,
+ struct vport_parms *parms)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->vport_new)
+ offload->vport_new(skb, vport, parms);
+}
+
+static inline void ovs_offload_vport_set(struct sk_buff *skb,
+ struct vport *vport)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->vport_set)
+ offload->vport_set(skb, vport);
+}
+
+static inline void ovs_offload_vport_del(struct sk_buff *skb,
+ struct vport *vport)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->vport_del)
+ offload->vport_del(skb, vport);
+}
+
+static inline void
+ovs_offload_vport_stats_get(struct vport *vport,
+ struct ovs_vport_stats *vport_stats)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->vport_stats_get)
+ offload->vport_stats_get(vport, vport_stats);
+}
+
+static inline void
+ovs_offload_vport_stats_set(struct vport *vport,
+ struct ovs_vport_stats *vport_stats)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->vport_stats_set)
+ offload->vport_stats_set(vport, vport_stats);
+}
+
+/* Datapath offload functions */
+static inline void ovs_offload_dp_new(struct datapath *dp)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->dp_new)
+ offload->dp_new(dp);
+}
+
+static inline void ovs_offload_dp_set(struct datapath *dp)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->dp_set)
+ offload->dp_set(dp);
+}
+
+static inline void ovs_offload_dp_del(struct datapath *dp)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->dp_del)
+ offload->dp_del(dp);
+}
+
+static inline void ovs_offload_dp_stats_get(struct datapath *dp,
+ struct ovs_dp_stats *stats)
+{
+ struct ovs_offload_ops *offload = rcu_dereference(offload_ops);
+
+ if (offload && offload->dp_stats_get)
+ offload->dp_stats_get(dp, stats);
+}
+
+#endif /* offload_ops.h */
diff --git a/datapath/vport.h b/datapath/vport.h
index 8c3da05..a2f2719 100644
--- a/datapath/vport.h
+++ b/datapath/vport.h
@@ -104,6 +104,7 @@ struct vport_portids {
* @stats_lock: Protects @err_stats and @offset_stats.
* @err_stats: Points to error statistics used and maintained by vport
* @offset_stats: Added to actual statistics as a sop to compatibility with
+ * @offload: Hardware offload callbacks
* XAPI for Citrix XenServer. Deprecated.
*/
struct vport {
@@ -121,6 +122,8 @@ struct vport {
spinlock_t stats_lock;
struct vport_err_stats err_stats;
struct ovs_vport_stats offset_stats;
+
+ void *offload;
};
/**
--
2.1.1
^ permalink raw reply related
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Dumazet @ 2014-10-08 1:28 UTC (permalink / raw)
To: Eric Wheeler; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <alpine.DEB.2.00.1410071746230.3503@ware.dreamhost.com>
On Tue, 2014-10-07 at 17:48 -0700, Eric Wheeler wrote:
> Just += unmap->vector.len still did not work (same backtrace), so I've
> rebuilt with PAGE_SIZE<<2 and so far so good. I'll let it run all night
> and see if we get any problems.
Further inspection of the driver told me that unmap->vector.len should
be 16384 already. (same than PAGE_SIZE << 2)
(set at line 304, drivers/net/ethernet/brocade/bna/bnad.c)
So you might hit memory fragmentation issues.
Do you have CONFIG_COMPACTION=y in your .config ?
^ permalink raw reply
* RE: r8168 is needed to enter P-state: Package State6(pc6)onHaswellhardware
From: Hayes Wang @ 2014-10-08 2:35 UTC (permalink / raw)
To: Francois Romieu; +Cc: Ceriel Jacobs, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <20141007201713.GB4398@zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Wednesday, October 08, 2014 4:17 AM
[...]
> > When enabling the ASPM, it would influence the thrpughput.
> > It is hard to
> > choose performance or power saving. Therefore, we reserve the config
> > to let the user determines it.
>
> Mmmm...
>
> How do Realtek's devices behave if Config{2, 3} + MISC registers are
> configured for ASPM whereas PCI config space registers aren't ?
The feature of the ASPM for the nic would be disabled.
ASPM is enabled when both the internal settings and
the PCI config space registers are enabled.
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH v1 4/4] ARM: Documentation: Update fec dts binding doc
From: luwei.zhou @ 2014-10-08 3:15 UTC (permalink / raw)
To: Richard Cochran
Cc: davem@davemloft.net, netdev@vger.kernel.org, shawn.guo@linaro.org,
bhutchings@solarflare.com, Fabio.Estevam@freescale.com,
fugang.duan@freescale.com, Frank.Li@freescale.com,
stephen@networkplumber.org
In-Reply-To: <20141001035900.GA4544@netboy>
On Wed, Oct 1, 2014 at 11:59:00AM, Richard Cochran wrote:
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Wednesday, October 01, 2014 11:59 AM
> To: Zhou Luwei-B45643
> Cc: davem@davemloft.net; netdev@vger.kernel.org; shawn.guo@linaro.org;
> bhutchings@solarflare.com; Estevam Fabio-R49496; Duan Fugang-B38611; Li
> Frank-B20596; stephen@networkplumber.org
> Subject: Re: [PATCH v1 4/4] ARM: Documentation: Update fec dts binding
> doc
>
> On Thu, Sep 25, 2014 at 04:43:50PM +0200, Richard Cochran wrote:
> > On Thu, Sep 25, 2014 at 04:10:21PM +0800, Luwei Zhou wrote:
> > > This patch update fec devicetree binding doc that add Optional
> > > properties "pps-channel".
> >
> > Again, use the PTP pin interface. We don't need a random new FEC DT
> > property for this.
>
> BTW, if the "channel" only means an internal timer resource, please find
> a proper way to claim that resource. Do not add another random DT
> property. We have enough of those already.
>
> Thanks,
> Richard
Okay. I will use the PTP pin interface to let user set the channel index as V2 patch does. Sorry for the
late reply caused by vocation.
Thanks,
Luwei
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox