On 2015/4/15 22:19, Arnd Bergmann wrote:
> On Wednesday 15 April 2015 20:30:06 Ding Tianhong wrote:
>> @@ -489,6 +487,8 @@ static int hip04_mac_start_xmit(struct sk_buff *skb,
>> struct net_device *ndev)
>>
>> /* Ensure tx_head update visible to tx reclaim */
>> smp_wmb();
>> +
On 2015/4/15 22:13, Arnd Bergmann wrote:
> On Wednesday 15 April 2015 20:30:04 Ding Tianhong wrote:
>> The hip04 ethernet use the big endian for tx and rx, so set desc to
>> big endian and remove the unused next_addr.
>
> I don't understand:
>
>> diff --git a/drivers/net/ethernet/hisilicon/hip04_
On 2015/4/15 22:25, Arnd Bergmann wrote:
> On Wednesday 15 April 2015 20:30:02 Ding Tianhong wrote:
>> The patches series was used to fix the issues of the hip04 driver, and added
>> some optimizations according to some good suggestion.
>>
>>
>
> Thanks, that looks much better, except for patch 4
On 15.04, Jesper Dangaard Brouer wrote:
> > Out of curiosity, what is actually the performance impact on all
> > of this? We were just arguing on a different matter on two more
> > instructions in the fast-path, here it's refactoring the whole
> > function into several ones, I presume gcc won't inl
On 16.04, Herbert Xu wrote:
> On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
> >
> > Netfilter may change the contents of the packet, even change its size.
> > It is *really* hard to do this while keeping the original fragments
> > intact.
>
> Perhaps we should provide better hel
On Thu, Apr 16, 2015 at 06:24:00AM +0100, Patrick McHardy wrote:
>
> Netfilter may change the contents of the packet, even change its size.
> It is *really* hard to do this while keeping the original fragments
> intact.
Perhaps we should provide better helpers to facilitate this?
So instead of di
On 16.04, Herbert Xu wrote:
> David Miller wrote:
> >
> > Because then there is no ambiguity at all, you preserve on output
> > exactly what you had on input. The same geometry, the same
> > everything. No special checks, no max frag len, none of this crap.
> > Those are all hacks trying to wor
Hi,
Ulf Samuelsson wrote:
> The desired functionality is that if communication stops,
> you want to send out ARP probes, before the entry is deleted.
>
> The current (pseudo) code of the neigh timer is:
>
> if (state & NUD_REACHABLE) {
> if (now <= "confirmed + "reachable_time")) {
Return correct error code if _mv88e6xxx_reg_read returns an error.
Fixes: facd95b2e0ec0 ("net: dsa: mv88e6xxx: Add Hardware bridging support")
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/mv88e6xxx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e
David Miller wrote:
>
> Because then there is no ambiguity at all, you preserve on output
> exactly what you had on input. The same geometry, the same
> everything. No special checks, no max frag len, none of this crap.
> Those are all hacks trying to work around the _fundamental_ issue
> which
On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
>
> An alternative... is to just ioremap_wc() the entire region, including
> MMIO registers for these old devices. I see one ethernet driver that does
> this, myri10ge, and am curious how and why they ended up deciding this
> and i
On Thu, 2015-04-16 at 12:20 +0800, Herbert Xu wrote:
> Eric Dumazet wrote:
> >
> > We already have netdev->gso_max_size and netdev->gso_max_segs
> > which are cached into sk->sk_gso_max_size & sk->sk_gso_max_segs
>
> It is quite dangerous to attempt tricks like this because a
> tc redirection or
Eric Dumazet wrote:
>
> We already have netdev->gso_max_size and netdev->gso_max_segs
> which are cached into sk->sk_gso_max_size & sk->sk_gso_max_segs
It is quite dangerous to attempt tricks like this because a
tc redirection or netfilter nat could change the destination
device rendering such hi
On 4/15/2015 3:54 AM, Ian Jackson wrote:
Prashant writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more
messages]"):
I tried to reproduce the problem on 32 bit 3.14.34 stable kernel
baremetal, with iommu=soft swiotlb=force but no luck, no drops or
errors. I did not try with Xen 64 bi
On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
> Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
> full range ioremap_wc() idea below.
>
> On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
> > Hi All,
> >
> > On Mon, 2015-04-13 at 19:49 +0200, Lu
On Wed, 2015-04-15 at 11:58 +0300, Or Gerlitz wrote:
> On Wed, Apr 15, 2015 at 7:51 AM, Jeff Kirsher
> wrote:
> > From: Anjali Singhai Jain
>
> > With this patch we can now add Flow director Sideband rules for a VF
> from
> > it's PF. Here is an example on how it can be done when VF id = 5 and
>
On Wed, 2015-04-15 at 21:54 +, Hubbe, Allen wrote:
> I ran with the --fix option, and it changed every rejected indent to
> match the column of the open paren. That's probably what you want,
> since it's the most consistent with the previous behavior. The
> difference is that it does not fix
On Wed, Apr 15, 2015 at 05:41:26PM +0200, Nicolas Dichtel wrote:
> Le 15/04/2015 15:57, Herbert Xu a écrit :
> >On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
> [snip]
> >Subject: skbuff: Do not scrub skb mark within the same name space
> >
> >The commit ea23192e8e577dfc51e0f4fc5ca113a
Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
full range ioremap_wc() idea below.
On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
> Hi All,
>
> On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
> > From the beginning it seems only framebuffer de
On Wed, Apr 8, 2015 at 7:41 AM, Jim Davis wrote:
> DOCPROC Documentation/DocBook/80211.xml
> Error(.//include/net/mac80211.h:329): Cannot parse enum!
> Error(.//include/net/mac80211.h:367): Cannot parse enum!
> Warning(.//include/net/mac80211.h:381): No description found for
> parameter 'type'
>
1.
first bug is a silly mistake. It broke tracing examples and prevented
simple bpf programs from loading.
In the following code:
if (insn->imm == 0 && BPF_SIZE(insn->code) == BPF_W) {
} else if (...) {
// this part should have been executed when
// insn->code == BPF_W and insn->imm != 0
}
Ob
On Wed, 2015-04-15 at 17:38 -0400, rapier wrote:
> I believe I properly disabled CPU power management in the bios (the
> lenovo bios isn't terribly clear on this). I then booted with
> processor.max_cstate=1 idle=poll (also tried with
> intel_idle.max_cstate=0 and combinatiosn thereof). Still s
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Wednesday, April 15, 2015 5:07 PM
> To: Hubbe, Allen
> Cc: a...@canonical.com; LKML; netdev
> Subject: CodingStyle parenthesis alignment: was: Re: align to open paren
>
> On Wed, 2015-04-15 at 20:34 +, Hubbe, Al
From: Jeff Kirsher
Date: Tue, 14 Apr 2015 21:51:37 -0700
> This series contains updates to i40e and i40evf.
Pulled, thanks Jeff.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
On 4/15/15 5:01 PM, Eric Dumazet wrote:
On Wed, 2015-04-15 at 15:31 -0400, rapier wrote:
All,
First, my apologies if this came up previously but I couldn't find
anything using a keyword search of the mailing list archive.
As part of the on going work with web10g I need to come up with baseli
On 04/15/2015 12:31 PM, rapier wrote:
All,
First, my apologies if this came up previously but I couldn't find
anything using a keyword search of the mailing list archive.
As part of the on going work with web10g I need to come up with baseline
TCP stack performance for various kernel revision.
From: Eric Dumazet
Date: Tue, 14 Apr 2015 18:45:00 -0700
> From: Eric Dumazet
>
> Commit 9a2620c877454 ("bnx2x: prevent WARN during driver unload")
> switched the napi/busy_lock locking mechanism from spin_lock() into
> spin_lock_bh(), breaking inter-operability with netconsole, as netpoll
> di
From: Thomas Gleixner
Date: Tue, 14 Apr 2015 21:42:42 +0200 (CEST)
> The code sets the expiry value of the timer to a relative value and
> starts it with hrtimer_start_expires. That's fine, but that only works
> once. The timer is started in relative mode, so the expiry value gets
> overwritten w
From: Rafał Miłecki
Date: Wed, 15 Apr 2015 22:21:49 +0200
> I guess the decisions depends on
> a) time needed for David to revert fc300dc & send pull request
> vs.
> b) time needed for Ralf to send pull request
Let's just wait for Ralf's stuff to hit Linus's tree.
--
To unsubscribe from this lis
On Wed, 2015-04-15 at 20:34 +, Hubbe, Allen wrote:
> Hello Andy, Joe,
Hello Allen.
As this is a discussion better suited for linux
development lists I've cc'd LKML and netdev.
> I would like to find the origin of the decision to align to the open
> paren in Linux.
Mostly it's a style decisi
On Wed, 2015-04-15 at 15:31 -0400, rapier wrote:
> All,
>
> First, my apologies if this came up previously but I couldn't find
> anything using a keyword search of the mailing list archive.
>
> As part of the on going work with web10g I need to come up with baseline
> TCP stack performance for
Add defines and documentation for enabling flow control on the stmmac. Flow
control was not implemented correctly on the stmmac driver and is currently
non-functional as a result. This is the first in a series of small patches
to correctly implement this feature.
Signed-off-by: Vince Bridgers
---
The Synopsys stmmac fifo sizes are configurable, and need to be known
in order to configure certain controller features. This patch adds
tx-fifo-depth and rx-fifo-depth properties to the stmmac document
file.
Signed-off-by: Vince Bridgers
---
Documentation/devicetree/bindings/net/ethernet.txt |
Unicast pause frame detect was not being enabled for the Synopsys stmmac. This
patch sets Unicast pause frame detect in MAC register 6 so that pause frame
detection by the stmmac conforms to IEEE 802.3, Annex 31B.3.3 Receive
Operation - Specifically, a MAC shall respond to pause frames containing
e
On Wed, Apr 15, 2015 at 10:21:49PM +0200, Rafał Miłecki wrote:
> On 15 April 2015 at 22:05, Guenter Roeck wrote:
> > arm:allmodconfig fails to build as follows since ARCH_BCM_5301X
> > is configured but not BCM47XX.
> >
> > drivers/net/ethernet/broadcom/bgmac.c: In function 'bgmac_probe':
> > driv
Read the tx-fifo-depth and rx-fifo-depth from the devicetree. The Synopsys
stmmac controller fifos are configurable per product instance, and the fifo
sizes are needed to configure certain features correctly such as flow control.
Signed-off-by: Vince Bridgers
---
drivers/net/ethernet/stmicro/stm
Configure flow control correctly, and based on the receive fifo size read
as a property from the devicetree since the Synopsys stmmac fifo sizes are
configurable based on a particular chip's implementation. This patch maintains
the previous incorrect behavior unless the receive fifo size is found i
This series of patches corrects flow control configuration for the Synopsys
GMAC driver.
Flow control is configured based on a configurable receive fifo size. If
less than 4Kbytes flow control is left disabled and a warning is presented. If
a receive fifo size is not specified, flow control is lef
All,
First, my apologies if this came up previously but I couldn't find
anything using a keyword search of the mailing list archive.
As part of the on going work with web10g I need to come up with baseline
TCP stack performance for various kernel revision. Using netperf and
super_netperf* I'
On 15 April 2015 at 22:05, Guenter Roeck wrote:
> arm:allmodconfig fails to build as follows since ARCH_BCM_5301X
> is configured but not BCM47XX.
>
> drivers/net/ethernet/broadcom/bgmac.c: In function 'bgmac_probe':
> drivers/net/ethernet/broadcom/bgmac.c:1643:2: error:
> implicit
On 04/15/2015 11:32 AM, Eric Dumazet wrote:
On Wed, 2015-04-15 at 11:19 -0700, Rick Jones wrote:
Well, I'm not sure that it is George and Jonathan themselves who don't
want to change a sysctl, but the customers who would have to tweak that
in their VMs?
Keep in mind some VM users install cust
arm:allmodconfig fails to build as follows since ARCH_BCM_5301X
is configured but not BCM47XX.
drivers/net/ethernet/broadcom/bgmac.c: In function 'bgmac_probe':
drivers/net/ethernet/broadcom/bgmac.c:1643:2: error:
implicit declaration of function 'bcm47xx_nvram_getenv'
Fixes: fc30
For the short-term solution, lets fix bpf helper functions to use
skb->mac_header relative offsets instead of skb->data in order to
get the same eBPF programs with cls_bpf and act_bpf work on ingress
and egress qdisc path. We need to ensure that mac_header is set
before calling into programs. This
On Wed, Apr 15, 2015, at 16:52, Daniel Borkmann wrote:
> This work follows upon commit 6256f8c9e45f ("tc, bpf: finalize eBPF
> support for cls and act front-end") and takes up the idea proposed by
> Hannes Frederic Sowa to spawn a shell (or any other command) that holds
> generated eBPF map file de
Fixes: 7a6c8c34e5b7 ("fou: implement FOU_CMD_GET")
Reported-by: Dan Carpenter
Cc: Dan Carpenter
Signed-off-by: Cong Wang
---
net/ipv4/fou.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index af150b4..34968cd 100644
--- a/net/ipv4/fou.c
++
Wed, Apr 15, 2015 at 08:42:12PM CEST, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Wed, 15 Apr 2015 20:38:15 +0200
>
>> Wed, Apr 15, 2015 at 07:54:56PM CEST, go...@cumulusnetworks.com wrote:
>>>On Mon, Apr 13, 2015 at 11:25:02PM +0200, Jiri Pirko wrote:
Turned out that "switchdev" stic
From: Jiri Pirko
Date: Wed, 15 Apr 2015 20:38:15 +0200
> Wed, Apr 15, 2015 at 07:54:56PM CEST, go...@cumulusnetworks.com wrote:
>>On Mon, Apr 13, 2015 at 11:25:02PM +0200, Jiri Pirko wrote:
>>> Turned out that "switchdev" sticks. So just unify all releated terms to
>>> use this prefix.
>>>
>>> J
Wed, Apr 15, 2015 at 07:54:56PM CEST, go...@cumulusnetworks.com wrote:
>On Mon, Apr 13, 2015 at 11:25:02PM +0200, Jiri Pirko wrote:
>> Turned out that "switchdev" sticks. So just unify all releated terms to
>> use this prefix.
>>
>> Jiri Pirko (2):
>> switchdev: s/netdev_switch_/switchdev_/ and
From: Eric Dumazet
Date: Wed, 15 Apr 2015 11:22:44 -0700
> On Wed, 2015-04-15 at 19:00 +0100, Ben Hutchings wrote:
>> Commit 355a901e6cf1 ("tcp: make connect() mem charging friendly")
>> changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
>> skb rather than using skb_copy_expan
On Wed, 2015-04-15 at 11:19 -0700, Rick Jones wrote:
> Well, I'm not sure that it is George and Jonathan themselves who don't
> want to change a sysctl, but the customers who would have to tweak that
> in their VMs?
Keep in mind some VM users install custom qdisc, or even custom TCP
sysctls.
On Wed, 2015-04-15 at 19:04 +0100, George Dunlap wrote:
> Maybe you should stop wasting all of our time and just tell us what
> you're thinking.
I think you make me wasting my time.
I already gave all the hints in prior discussions.
Rome was not built in one day.
--
To unsubscribe from this l
On Wed, 2015-04-15 at 19:00 +0100, Ben Hutchings wrote:
> Commit 355a901e6cf1 ("tcp: make connect() mem charging friendly")
> changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
> skb rather than using skb_copy_expand().
>
> The open-coded copy does not cover the skb_shared_info
On 04/15/2015 11:08 AM, Eric Dumazet wrote:
On Wed, 2015-04-15 at 10:55 -0700, Rick Jones wrote:
Have you tested this patch on a NIC without GSO/TSO ?
This would allow more than 500 packets for a single flow.
Hello bufferbloat.
Woudln't the fq_codel qdisc on that interface address that prob
On Wed, 2015-04-15 at 18:58 +0100, Stefano Stabellini wrote:
> On Wed, 15 Apr 2015, Eric Dumazet wrote:
> > On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
> >
> > > Which means that max(2*skb->truesize, sk->sk_pacing_rate >>10) is
> > > *already* larger for Xen; that calculation mentioned
On Wed, 2015-04-15 at 10:55 -0700, Rick Jones wrote:
> >
> > Have you tested this patch on a NIC without GSO/TSO ?
> >
> > This would allow more than 500 packets for a single flow.
> >
> > Hello bufferbloat.
>
> Woudln't the fq_codel qdisc on that interface address that problem?
Last time I check
On 04/15/2015 06:52 PM, Eric Dumazet wrote:
> On Wed, 2015-04-15 at 18:41 +0100, George Dunlap wrote:
>
>> So you'd be OK with a patch like this? (With perhaps a better changelog?)
>>
>> -George
>>
>> ---
>> TSQ: Raise default static TSQ limit
>>
>> A new dynamic TSQ limit was introduced in c/s
On Wed, 15 Apr 2015, Eric Dumazet wrote:
> On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
>
> > Which means that max(2*skb->truesize, sk->sk_pacing_rate >>10) is
> > *already* larger for Xen; that calculation mentioned in the comment is
> > *already* doing the right thing.
>
> Sigh.
>
>
Commit 355a901e6cf1 ("tcp: make connect() mem charging friendly")
changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
skb rather than using skb_copy_expand().
The open-coded copy does not cover the skb_shared_info::gso_segs
field, so in the new skb it is left set to 0. When thi
Have you tested this patch on a NIC without GSO/TSO ?
This would allow more than 500 packets for a single flow.
Hello bufferbloat.
Woudln't the fq_codel qdisc on that interface address that problem?
rick
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a m
On Mon, Apr 13, 2015 at 11:25:02PM +0200, Jiri Pirko wrote:
> Turned out that "switchdev" sticks. So just unify all releated terms to
> use this prefix.
>
> Jiri Pirko (2):
> switchdev: s/netdev_switch_/switchdev_/ and
> s/NETDEV_SWITCH_/SWITCHDEV_/
> switchdev: s/swdev_/switchdev_/
>
>
On Wed, 2015-04-15 at 18:41 +0100, George Dunlap wrote:
> So you'd be OK with a patch like this? (With perhaps a better changelog?)
>
> -George
>
> ---
> TSQ: Raise default static TSQ limit
>
> A new dynamic TSQ limit was introduced in c/s 605ad7f18 based on the
> size of actual packets and t
On 04/15/2015 06:29 PM, Eric Dumazet wrote:
> On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
>> On 04/15/2015 05:38 PM, Eric Dumazet wrote:
>>> My thoughts that instead of these long talks you should guys read the
>>> code :
>>>
>>> /* TCP Small Queues :
>>>
On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
> Which means that max(2*skb->truesize, sk->sk_pacing_rate >>10) is
> *already* larger for Xen; that calculation mentioned in the comment is
> *already* doing the right thing.
Sigh.
1ms of traffic at 40Gbit is 5 MBytes
The reason for the c
On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
> On 04/15/2015 05:38 PM, Eric Dumazet wrote:
> > My thoughts that instead of these long talks you should guys read the
> > code :
> >
> > /* TCP Small Queues :
> > * Control number of packets in qdisc/devices
On 04/15/2015 05:38 PM, Eric Dumazet wrote:
> My thoughts that instead of these long talks you should guys read the
> code :
>
> /* TCP Small Queues :
> * Control number of packets in qdisc/devices to two packets
> / or ~1 ms.
> * This allows for
On Wed, 2015-04-15 at 14:03 +, Yuval Mintz wrote:
> > >
> > > BTW, this looks quite generic - isn't it possible to take it out of
> > > the driver and push it into the networking core, uniforming it in the
> > > process?
> >
> > Yes, this is the plan I have in mind, once net-next is opened ag
On 04/15/2015 12:57 AM, Alexei Starovoitov wrote:
Due to missing bounds check the DAG pass of the BPF verifier can corrupt
the memory which can cause random crashes during program loading:
[8.449451] BUG: unable to handle kernel paging request at
[8.451293] IP: [] kmem_cache_all
On Wed, 2015-04-15 at 15:36 +0100, Ian Campbell wrote:
> On Wed, 2015-04-15 at 15:19 +0100, George Dunlap wrote:
> > On Mon, Apr 13, 2015 at 4:03 PM, Malcolm Crossley
> [...]
> > > From a networking point of view, the backend is a switch. Is it OK to
> > > consider the packet to have been transmitt
On Wed, 2015-04-15 at 14:43 +0100, George Dunlap wrote:
> On Mon, Apr 13, 2015 at 2:49 PM, Eric Dumazet wrote:
> > On Mon, 2015-04-13 at 11:56 +0100, George Dunlap wrote:
> >
> >> Is the problem perhaps that netback/netfront delays TX completion?
> >> Would it be better to see if that can be addre
On 04/14/2015 01:15 AM, Johannes Berg wrote:
> On Fri, 2015-04-03 at 14:12 -0700, gree...@candelatech.com wrote:
>
>> +/* Auxilary info to allow user-space to better understand the rate */
>> +struct hwsim_tx_rate2 {
>> +u16 rc_flags; /* rate-ctrl flags (see mac80211_rate_control_flags) */
>
On Wed, Apr 15, 2015 at 12:35:16AM -0700, John Fastabend wrote:
>
> I'll dig up my scripts and post them to github this weekend. They
> are a bit organized and all over the place at the moment.
>
> Maybe we can build a master repository. I know there a lot of different
> scripts running around, fo
On Wed, Apr 15, 2015, at 18:07, Alexei Starovoitov wrote:
> On 4/15/15 8:59 AM, Hannes Frederic Sowa wrote:
> > On Di, 2015-04-14 at 15:57 -0700, Alexei Starovoitov wrote:
> >> Due to missing bounds check the DAG pass of the BPF verifier can corrupt
> >> the memory which can cause random crashes du
On Wed, Apr 15, 2015 at 06:34:27PM +0530, Varun Prakash wrote:
> On Mon, Apr 13, 2015 at 10:38:08AM -0600, Jason Gunthorpe wrote:
> > On Mon, Apr 13, 2015 at 07:34:23PM +0530, Varun Prakash wrote:
> > > define struct ulptx_idata in common header file t4_msg.h
> > > to remove duplicate definitions.
On Fri, 10 Apr 2015 15:47:34 +0200
Daniel Borkmann wrote:
> On 04/10/2015 02:15 PM, Pablo Neira Ayuso wrote:
> > This patch splits __netif_receive_skb_core() in smaller functions to improve
> > maintainability.
> >
> > The function __netif_receive_skb_core() has been split in two:
> >
> > * __net
On Wed, Apr 15, 2015 at 09:17:14AM +0300, Erez Shitrit wrote:
> >>+ /* parent interface */
> >>+ if (!test_bit(IPOIB_FLAG_SUBINTERFACE, &priv->flags))
> >>+ return dev->ifindex;
> >>+
> >>+ /* child/vlan interface */
> >>+ if (!priv->parent)
> >>+
On 4/15/15 8:59 AM, Hannes Frederic Sowa wrote:
On Di, 2015-04-14 at 15:57 -0700, Alexei Starovoitov wrote:
Due to missing bounds check the DAG pass of the BPF verifier can corrupt
the memory which can cause random crashes during program loading:
[8.449451] BUG: unable to handle kernel paging r
From: David Laight
Date: Wed, 15 Apr 2015 08:37:01 +
> From: David Miller
>> Sent: 14 April 2015 18:56
>> > On Tue, Apr 14, 2015 at 04:25:24PM +, David Laight wrote:
>> >> From: Al Viro
>> >> > Sent: 11 April 2015 22:18
>> >> > it's equal to iov_iter_count(&msg->msg_iter) in all cases
>>
On Di, 2015-04-14 at 15:57 -0700, Alexei Starovoitov wrote:
> Due to missing bounds check the DAG pass of the BPF verifier can corrupt
> the memory which can cause random crashes during program loading:
>
> [8.449451] BUG: unable to handle kernel paging request at
> [8.451293] IP:
Le 15/04/2015 15:57, Herbert Xu a écrit :
On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
[snip]
Subject: skbuff: Do not scrub skb mark within the same name space
The commit ea23192e8e577dfc51e0f4fc5ca113af334edff9 ("tunnels:
Maybe add a Fixes tag?
Fixes: ea23192e8e57 ("tunnels: h
This work follows upon commit 6256f8c9e45f ("tc, bpf: finalize eBPF
support for cls and act front-end") and takes up the idea proposed by
Hannes Frederic Sowa to spawn a shell (or any other command) that holds
generated eBPF map file descriptors.
File descriptors, based on their id, are being fetc
On Wed, 2015-04-15 at 15:19 +0100, George Dunlap wrote:
> On Mon, Apr 13, 2015 at 4:03 PM, Malcolm Crossley
[...]
> > From a networking point of view, the backend is a switch. Is it OK to
> > consider the packet to have been transmitted from the guest point of
> > view once the backend is aware of
On Wednesday 15 April 2015 20:30:02 Ding Tianhong wrote:
> The patches series was used to fix the issues of the hip04 driver, and added
> some optimizations according to some good suggestion.
>
>
Thanks, that looks much better, except for patch 4 that I commented on.
I had at some point sent a
On Wednesday 15 April 2015 20:30:08 Ding Tianhong wrote:
> There can be quite a lot of rx/tx drops message and affect
> useful message, so need to ratelimit them to not overwhelm
> logging.
>
> Signed-off-by: Ding Tianhong
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> Cc: Arnd Bergmann
> Cc: Zh
On Mon, Apr 13, 2015 at 4:03 PM, Malcolm Crossley
wrote:
>>
>> But the main concern here is it basically breaks back pressure.
>>
>> And you do not want this, unless there is no other choice.
>>
>
> virtio_net already use's skb_orphan() in it's transmit path. It seems
> only fair that other virtua
On Wednesday 15 April 2015 20:30:06 Ding Tianhong wrote:
> @@ -489,6 +487,8 @@ static int hip04_mac_start_xmit(struct sk_buff *skb,
> struct net_device *ndev)
>
> /* Ensure tx_head update visible to tx reclaim */
> smp_wmb();
> + count++;
> + priv->tx_head = TX_NEXT(t
On Wednesday 15 April 2015 20:30:05 Ding Tianhong wrote:
> The driver will alloc some skb buffer for hareware queue, but without
> considering the case of memory allocation failure, when memory is low,
> the skb may be null and panic the system, so break the loop when skb is
> null and try to alloc
On Wednesday 15 April 2015 20:30:07 Ding Tianhong wrote:
> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
> b/drivers/net/ethernet/hisilicon/hip04_eth.c
> index ff9d19c..a7ab1d9 100644
> --- a/drivers/net/ethernet/hisilicon/hip04_eth.c
> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
>
On Wednesday 15 April 2015 20:30:04 Ding Tianhong wrote:
> The hip04 ethernet use the big endian for tx and rx, so set desc to
> big endian and remove the unused next_addr.
I don't understand:
> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
> b/drivers/net/ethernet/hisilicon/hip04_eth.
On Wednesday 15 April 2015 20:30:03 Ding Tianhong wrote:
> According Arnd's suggestion, the user might set the tx coalesce value
> in large range for different workloads, so we should define them to
> appropriate value.
>
> Signed-off-by: Ding Tianhong
> Cc: "David S. Miller"
> Cc: Eric Dumazet
> >
> > BTW, this looks quite generic - isn't it possible to take it out of
> > the driver and push it into the networking core, uniforming it in the
> > process?
>
> Yes, this is the plan I have in mind, once net-next is opened again ;)
>
> Thanks !
>
I'm not familiar with any real strong tes
On Wed, Apr 15, 2015 at 06:22:29PM +0800, Herbert Xu wrote:
>
> Yes this is better. I'm currently auditing all the other bits
> that are cleared to see if there is anything else that we should
> preserve for tunneling.
OK the only other thing that we may wish to preserve is secmark.
James, can yo
On Mon, Apr 13, 2015 at 2:49 PM, Eric Dumazet wrote:
> On Mon, 2015-04-13 at 11:56 +0100, George Dunlap wrote:
>
>> Is the problem perhaps that netback/netfront delays TX completion?
>> Would it be better to see if that can be addressed properly, so that
>> the original purpose of the patch (fight
No reply on this
in net/core/neighbour.c: neigh_timer_handler I see:
if (state & NUD_REACHABLE) {
if (time_before_eq(now,
neigh->confirmed + neigh->parms->reachable_time)) {
neigh_dbg(2, "neigh %p is still alive\n", neigh);
next = neigh-
On 04/15/2015 05:44 AM, David Laight wrote:
From: Alexander Duyck
Sent: 10 April 2015 20:56
On 04/10/2015 05:15 AM, Pablo Neira Ayuso wrote:
+another_round:
+ ret = __netif_receive_skb_ingress(skb, pfmemalloc, orig_dev);
+ switch (ret) {
+ case NET_RX_SUCCESS:
+ case N
On Mon, Apr 13, 2015 at 10:38:08AM -0600, Jason Gunthorpe wrote:
> On Mon, Apr 13, 2015 at 07:34:23PM +0530, Varun Prakash wrote:
> > define struct ulptx_idata in common header file t4_msg.h
> > to remove duplicate definitions.
>
> The Infiniband side of this patch looks OK.
>
> Reviewed-By: Jaso
From: Alexander Duyck
> Sent: 10 April 2015 20:56
> On 04/10/2015 05:15 AM, Pablo Neira Ayuso wrote:
> > +another_round:
> > + ret = __netif_receive_skb_ingress(skb, pfmemalloc, orig_dev);
> > + switch (ret) {
> > + case NET_RX_SUCCESS:
> > + case NET_RX_DROP:
> > + break;
> > +
According Arnd's suggestion, the user might set the tx coalesce value
in large range for different workloads, so we should define them to
appropriate value.
Signed-off-by: Ding Tianhong
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Arnd Bergmann
Cc: Zhangfei Gao
Cc: Dan Carpenter
Cc: Joe Perche
The hip04 ethernet use the big endian for tx and rx, so set desc to
big endian and remove the unused next_addr.
Signed-off-by: Ding Tianhong
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Arnd Bergmann
Cc: Zhangfei Gao
Cc: Dan Carpenter
Cc: Joe Perches
---
drivers/net/ethernet/hisilicon/hip04_
The driver will alloc some skb buffer for hareware queue, but without
considering the case of memory allocation failure, when memory is low,
the skb may be null and panic the system, so break the loop when skb is
null and try to alloc the memory again to fix this problem.
Signed-off-by: Ding Tianh
Testing bytes_compl should be enough, because there is no way
that pkt_compl could be 0 if bytes_compl is not 0.
Signed-off-by: Ding Tianhong
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Arnd Bergmann
Cc: Zhangfei Gao
Cc: Dan Carpenter
Cc: Joe Perches
---
drivers/net/ethernet/hisilicon/hip04
1 - 100 of 123 matches
Mail list logo
