This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon Hip05-D02 development board.
Signed-off-by: yankejian
---
.../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devic
enet is associating with dasf. before this patch, the association is
the same strings between ae-name and dsa-name. in a general way, enet
specifies a reference to dsaf should be a good idea. so this patch
deletes the ae-name in enet, and adds parsing the ae-handle
from DT to set the associating wi
sorry, pls ignore this patchset.
On 2015/12/5 15:54, yankejian wrote:
> this patchset fixes the bug that eth can't initial successful on hip05-D02
> because the dts files doesn't match the source code.
>
> yankejian (3):
> dts: hisi: enables the ethX for D02 board
> dts: hisi: fixes no syscon
in this patchset, enet specifies a reference to dsaf. and delete the
ae-name in enet, and adds parsing the ae-handle from DT to set the
associating with dsaf.
the patchset updates the dtsi and bindings documents as well.
yankejian (2):
net: hns: enet specisies a reference to dsaf
net: hns: e
when enet specisies a reference to dsaf, the correlative config and
documents needs to update. this patch updates the correlative dtsi file
and bindings documents .
Signed-off-by: yankejian
---
.../devicetree/bindings/net/hisilicon-hns-dsaf.txt| 5 +
.../devicetree/bindings/net/hisilico
this patch enables the ethX for D02 board on hip05-d02.dts. otherwise it
cannot find hns ethX by ifconfig -a.
Signed-off-by: yankejian
---
arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
when linux start up, we get the log below:
"Hi-HNS_MDIO 803c.mdio: no syscon hisilicon,peri-c-subctrl
mdio_bus mdio@803c: mdio sys ctl reg has not maped "
the source code about the subctrl is dealled with syscon, but dts doesn't.
it cause such fault. so this patch adds the syscon in
this patchset fixes the bug that eth can't initial successful on hip05-D02
because the dts files doesn't match the source code.
yankejian (3):
dts: hisi: enables the ethX for D02 board
dts: hisi: fixes no syscon error when init mdio
arm64: hip05-d02: Document devicetree bindings for Hisilico
when linux start up, we get the log below:
"Hi-HNS_MDIO 803c.mdio: no syscon hisilicon,peri-c-subctrl
mdio_bus mdio@803c: mdio sys ctl reg has not maped "
the source code about the subctrl is dealled with syscon, but dts doesn't.
it cause such fault. so this patch adds the syscon in
This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon Hip05-D02 development board.
Signed-off-by: yankejian
---
.../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devic
this patchset fixes the bug that eth can't initial successful on hip05-D02
because the dts files doesn't match the source code.
yankejian (3):
dts: hisi: enables the ethX for D02 board
dts: hisi: fixes no syscon error when init mdio
arm64: hip05-d02: Document devicetree bindings for Hisilico
this patch enables the ethX for D02 board on hip05-d02.dts. otherwise it
cannot find hns ethX by ifconfig -a.
Signed-off-by: yankejian
---
arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
when A sends a data to B, then A close() and enter into SHUTDOWN_PENDING
state, if B neither claim his rwnd is 0 nor send SACK for this data, A
will keep retransmitting this data until t5 timeout, Max.Retrans times
can't work anymore, which is bad.
if B's rwnd is not 0, it should send abort after
When a msg is sent, sctp will hold the chunks of this msg and then try
to enqueue them. But if the chunks are not enqueued in sctp_outq_tail()
because of the invalid state, sctp_cmd_interpreter() may still return
success to sctp_sendmsg() after calling sctp_outq_flush(), these chunks
will become or
If the chunks are enqueued successfully but sctp_cmd_interpreter()
return err to sctp_sendmsg() (mainly because of no mem), the chunks will
get re-queued, but we are dropping the reference and freeing them.
The fix is to just drop the reference on the datamsg just as it had
succeeded, as:
- if th
here is the patch raising the performance of XGE by:
1)changes the way page management method for enet momery, and
2)reduces the count of rmb, and
3)adds Memory prefetching
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 5 +-
drivers/net/ethernet/hisilicon/hns/
On Fri, Dec 04, 2015 at 07:15:55PM +0100, Phil Sutter wrote:
>
> > Only one should really do this, while others are waiting.
>
> Sure, that was my previous understanding of how this thing works.
Yes that's clearly how it should be. Unfortunately while adding
the locking to do this, I found out t
On Fri, Dec 04, 2015 at 04:53:34PM -0500, David Miller wrote:
> From: Herbert Xu
> Date: Fri, 4 Dec 2015 22:39:56 +0800
>
> > When an rhashtable user pounds rhashtable hard with back-to-back
> > insertions we may end up growing the table in GFP_ATOMIC context.
> > Unfortunately when the table rea
On Fri, Dec 4, 2015 at 8:50 PM, David Miller wrote:
> From: Alexander Duyck
> Date: Fri, 4 Dec 2015 14:44:00 -0800
>
>> I actually tried to push the generic checksum idea for fm10k back
>> during hardware development but ended up losing that battle.
>
> This chips already have a circuit calculati
From: Alexander Duyck
Date: Fri, 4 Dec 2015 21:45:09 -0800
> Not having this feature has to in some way impact sales.
I'm glad money trumps clean design and performance these days.
Would they ship a literal turd until some customer asked for
something better? You have to be kidding me.
If it'
in this patchset, enet specifies a reference to dsaf. and delete the
ae-name in enet, and adds parsing the ae-handle from DT to set the
associating with dsaf.
the patchset updates the dtsi and bindings documents as well.
yankejian (2):
net: hns: enet specisies a reference to dsaf
net: hns: e
enet is associating with dasf. before this patch, the association is
the same strings between ae-name and dsa-name. in a general way, enet
specifies a reference to dsaf should be a good idea. so this patch
deletes the ae-name in enet, and adds parsing the ae-handle
from DT to set the associating wi
when enet specisies a reference to dsaf, the correlative config and
documents needs to update. this patch updates the correlative dtsi file
and bindings documents .
Signed-off-by: yankejian
---
.../devicetree/bindings/net/hisilicon-hns-dsaf.txt| 5 +
.../devicetree/bindings/net/hisilico
On 12/04/2015 04:53 PM, Tom Herbert wrote:
I actually tried to push the generic checksum idea for fm10k back
during hardware development but ended up losing that battle. The
problem is you have to have some customer willing to spend the cash in
order to get a feature, and the fact is nobody othe
From: Alexander Duyck
Date: Fri, 4 Dec 2015 14:44:00 -0800
> I actually tried to push the generic checksum idea for fm10k back
> during hardware development but ended up losing that battle.
This chips already have a circuit calculating the 1's complement sum
over the data as is passed through th
Hi all,
I've been trying to upgrade to something newer than 4.2.6 since I want
to use LVM Cache on my home NFS fileserver, KVM server, test server,
etc. So when it goes down, I lose all my other systems which mount
stuff from it.
Right now I'm trying to figure out how to use Netconsole to grab
My name is Brett McCorriston a merchant of Paris but currently base in Nevada
Las Vegas Cartgate Ct United states, I have been diagnosed with esophageal
cancer which has defiled all forms of medical treatment i have only few weeks
to live here on earth.My condition is really deteriorating. i h
On Thu, Dec 3, 2015 at 6:08 AM, <> wrote:
> From: Madalin Bucur
>
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).
Please fix your git-send-email configuration, so that your emails are
formatted properly. This is the From: header
Add myself as a reviewer for the Renesas Ethernet drivers -- hopefully I
won't miss the buggy patches anymore. :-)
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net.git' repo.
Changes in version 3:
- removed the status entry;
Changes in version 2:
- removed garbage from th
On Fri, Dec 4, 2015 at 8:24 AM, Sowmini Varadhan
wrote:
>
> [Apologies for fat-fingering subject in the other attempt]
>
> This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC
> address in Open Firmware or IDPROM").
>
> As with that fix, attempt to look up the MAC address in Ope
On Sat, 2015-12-05 at 04:13 +0300, Sergei Shtylyov wrote:
> On 12/05/2015 04:02 AM, Joe Perches wrote:
> > > Since you seem to be get_maintainers.pl maintainer, I (and not only I)
> > > would like to propose a switch to suppress the committers/authors/etc.
> > > It's
> > > generally annoying and u
On 12/05/2015 04:02 AM, Joe Perches wrote:
Since you seem to be get_maintainers.pl maintainer, I (and not only I)
would like to propose a switch to suppress the committers/authors/etc. It's
generally annoying and unhelpful to have the bunch of people listed, none of
which usually are a good addr
On Fri, Dec 04, 2015 at 07:26:12PM +0100, Stefan Priebe wrote:
>
> * 9f87e0c - (2 months ago) netlink: Replace rhash_portid with bound
> - Herbert Xu
> * 35e9890 - (3 months ago) netlink: Fix autobind race condition that
> leads to zero port ID - Herbert Xu
> * 30c6472 - (7 months ago) netlink: Use
On Sat, 2015-12-05 at 03:57 +0300, Sergei Shtylyov wrote:
> Since you seem to be get_maintainers.pl maintainer, I (and not only I)
> would like to propose a switch to suppress the committers/authors/etc. It's
> generally annoying and unhelpful to have the bunch of people listed, none of
> which u
Hello.
On 12/05/2015 03:41 AM, Joe Perches wrote:
liAdd myself as a reviewer for the Renesas Ethernet drivers --
hopefully I
won't miss the buggy patches anymore. :-)
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net.git' repo.
MAINTAINERS |8
1 file cha
> I actually tried to push the generic checksum idea for fm10k back
> during hardware development but ended up losing that battle. The
> problem is you have to have some customer willing to spend the cash in
> order to get a feature, and the fact is nobody other than Tom has been
> pushing for thi
On Sat, 2015-12-05 at 03:03 +0300, Sergei Shtylyov wrote:
> liAdd myself as a reviewer for the Renesas Ethernet drivers --
> hopefully I
> won't miss the buggy patches anymore. :-)
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against DaveM's 'net.git' repo.
>
> MAINTAINERS |
Add myself as a reviewer for the Renesas Ethernet drivers -- hopefully I
won't miss the buggy patches anymore. :-)
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net.git' repo.
Changes in version 2:
- remove garbage from the changelog.
MAINTAINERS |8
1 file c
liAdd myself as a reviewer for the Renesas Ethernet drivers -- hopefully I
won't miss the buggy patches anymore. :-)
Signed-off-by: Sergei Shtylyov
---
The patch is against DaveM's 'net.git' repo.
MAINTAINERS |8
1 file changed, 8 insertions(+)
Index: net/MAINTAINERS
==
On Tue, Dec 1, 2015 at 12:51 PM, Pablo Neira Ayuso wrote:
> On Wed, Nov 25, 2015 at 04:08:16PM -0800, Jarno Rajahalme wrote:
>> NAT checksum recalculation code assumes existence of skb_dst, which
>> becomes a problem for a later patch in the series ("openvswitch:
>> Interface with NAT."). Simplif
On Thu, 2015-12-03 at 16:54 -0800, Tom Herbert wrote:
> On Thu, Dec 3, 2015 at 4:29 PM, Jeff Kirsher
> wrote:
> > From: Jacob Keller
> >
> > The NVGRE protocol should be run over transparent ethernet bridge
> > protocol, so we should verify this in our check whether the GRE
> tunnel
> > is NVGRE.
Hello,
I ran into the following warning when running v4.4-rc3 on a TI OMAP4
(pandaboard) using nfsroot.
[ 8063.208526] [ cut here ]
[ 8063.213653] WARNING: CPU: 1 PID: 81 at net/ipv4/af_inet.c:155
inet_sock_destruct+0x188/0x1dc()
[ 8063.213653] Modules linked in: vivid c
On Fri, Dec 4, 2015 at 12:06 PM, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Fri, 04 Dec 2015 20:59:05 +0100
>
>> Yes, I agree, I am totally with you here. If generic offloading can be
>> realized by NICs I am totally with you that this should be the way to
>> go. I don't see that co
From: Pavel Machek
Date: Fri, 4 Dec 2015 22:30:27 +0100
> On Fri 2015-12-04 11:21:40, David Miller wrote:
>> From: Pavel Machek
>> Date: Fri, 4 Dec 2015 09:11:27 +0100
>>
>> >> >>if (unlikely(!ring_header->desc)) {
>> >> >> - dev_err(&pdev->dev, "pci_alloc_consistend failed
The code reading the MAHR/MALR registers in read_mac_address() is terribly
ineffective -- it reads MAHR 4 times and MALR 2 times, while it's enough to
read each register only once. Use the local variables to achieve that,
somewhat beautifying the code while at it...
Signed-off-by: Sergei Shtylyov
The code reading the MAHR/MALR registers in ravb_read_mac_address() is
terribly ineffective -- it reads MAHR 4 times and MALR 2 times, while
it's enough to read each register only once. Use the local variables to
achieve that, somewhat beautifying the code while at it...
Signed-off-by: Sergei Sht
From: Bjørn Mork
Date: Thu, 3 Dec 2015 19:24:17 +0100
> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis. But the Sierra Wireless MC
From: Nicolas Dichtel
Date: Thu, 3 Dec 2015 17:21:50 +0100
> Parameters were updated only if the kernel was unable to find the tunnel
> with the new parameters, ie only if core pamareters were updated (keys,
> addr, link, type).
> Now it's possible to update ttl, hoplimit, flowinfo and flags.
>
Hello.
Here's 2 patches against DaveM's 'net-next.git' repo. Here we optimize the
MAC address register reading (left over from a bootloader).
[1/2] ravb: read MAC address registers only once
[2/2] sh_eth: read MAC address registers only once
MBR, Sergei
--
To unsubscribe from this list: send
From: Herbert Xu
Date: Fri, 4 Dec 2015 22:39:56 +0800
> When an rhashtable user pounds rhashtable hard with back-to-back
> insertions we may end up growing the table in GFP_ATOMIC context.
> Unfortunately when the table reaches a certain size this often
> fails because we don't have enough physic
From: Guillaume Nault
Date: Thu, 3 Dec 2015 16:49:32 +0100
> pppoe_connect() mustn't touch the padt_work field of pppoe sockets
> because that work could be already pending.
...
> Reported-by: Andrew
> Fixes: 287f3a943fef ("pppoe: Use workqueue to die properly when a PADT is
> received")
> Sig
From: Alexei Starovoitov
Date: Fri, 4 Dec 2015 12:35:23 -0800
> On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote:
>>
>> For example, a compiler can assume that result of left shift is larger
>> or equal to first operand, which in turn can allow it to elide some
>> bounds check in co
On Fri, Dec 4, 2015 at 10:34 PM, Marcelo Ricardo Leitner
wrote:
> On Fri, Dec 04, 2015 at 09:25:35PM +0100, Dmitry Vyukov wrote:
>> On Fri, Dec 4, 2015 at 6:48 PM, Marcelo Ricardo Leitner
>> wrote:
>> > Hi Dmitry,
>> >
>> > Can you please test this patch?
>> > I'll re-post with proper subject if
From: Tom Herbert
Date: Fri, 4 Dec 2015 12:13:53 -0800
> On Fri, Dec 4, 2015 at 12:06 PM, David Miller wrote:
>> From: Hannes Frederic Sowa
>> Date: Fri, 04 Dec 2015 20:59:05 +0100
>>
>>> Yes, I agree, I am totally with you here. If generic offloading can be
>>> realized by NICs I am totally wi
On Fri, Dec 04, 2015 at 09:25:35PM +0100, Dmitry Vyukov wrote:
> On Fri, Dec 4, 2015 at 6:48 PM, Marcelo Ricardo Leitner
> wrote:
> > Hi Dmitry,
> >
> > Can you please test this patch?
> > I'll re-post with proper subject if it works.
>
> Still happening with the same stacks.
Then there may be a
Otto Sabart wrote:
> I probably found a performance regression on ixgbe (Intel 82599EB
> 10-Gigabit NIC) on v4.4-rc3. I am able to see this problem since
> v4.4-rc1.
>
> The bug report you can find here [0].
>
> Can somebody take a look at it?
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?i
On Friday 04 December 2015 11:12:30 Eric Dumazet wrote:
> On Fri, 2015-12-04 at 19:45 +0100, Gregory CLEMENT wrote:
> > With this patch each CPU is associated with its own set of TX queues. In
> > the same time the SKB received in mvneta_tx is bound to the queue
> > associated to the CPU sending th
On Fri 2015-12-04 11:21:40, David Miller wrote:
> From: Pavel Machek
> Date: Fri, 4 Dec 2015 09:11:27 +0100
>
> >> >> if (unlikely(!ring_header->desc)) {
> >> >> - dev_err(&pdev->dev, "pci_alloc_consistend failed\n");
> >> >> + dev_err(&pdev->dev, "could not ge
Hello,
On Fri, Dec 4, 2015, at 20:48, Dmitry Vyukov wrote:
> On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote:
> > From: Alexei Starovoitov
> > Date: Fri, 4 Dec 2015 11:10:15 -0800
> >
> >> just don't generate random bpf programs with such shifts.
> >
> > Agreed, it is exactly the same as if t
On Fri, Dec 4, 2015, at 21:43, Tom Herbert wrote:
> On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa
> wrote:
> > Hi Dave,
> >
> > On Fri, Dec 4, 2015, at 21:06, David Miller wrote:
> >> From: Hannes Frederic Sowa
> >> Date: Fri, 04 Dec 2015 20:59:05 +0100
> >>
> >> > Yes, I agree, I am tota
On Fri, Dec 04, 2015 at 12:44:09PM -0800, Kostya Serebryany wrote:
> On Fri, Dec 4, 2015 at 12:35 PM, Alexei Starovoitov <
> alexei.starovoi...@gmail.com> wrote:
>
> > On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote:
> > >
> > > For example, a compiler can assume that result of left
On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa
wrote:
> Hi Dave,
>
> On Fri, Dec 4, 2015, at 21:06, David Miller wrote:
>> From: Hannes Frederic Sowa
>> Date: Fri, 04 Dec 2015 20:59:05 +0100
>>
>> > Yes, I agree, I am totally with you here. If generic offloading can be
>> > realized by NIC
On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa
wrote:
> Hi Dave,
>
> On Fri, Dec 4, 2015, at 21:06, David Miller wrote:
>> From: Hannes Frederic Sowa
>> Date: Fri, 04 Dec 2015 20:59:05 +0100
>>
>> > Yes, I agree, I am totally with you here. If generic offloading can be
>> > realized by NIC
On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote:
>
> For example, a compiler can assume that result of left shift is larger
> or equal to first operand, which in turn can allow it to elide some
> bounds check in code, which in turn can lead to an exploit. I am not
> saying that this
On 12/04/2015 12:14 PM, Marcelo Ricardo Leitner wrote:
> As we are keeping timestamps on when copying the socket, we also have to
> copy sk_tsflags.
>
> This is needed since b9f40e21ef42 ("net-timestamp: move timestamp flags
> out of sk_flags").
>
> Signed-off-by: Marcelo Ricardo Leitner
Acked-
On 12/04/2015 12:14 PM, Marcelo Ricardo Leitner wrote:
> Dmitry Vyukov reported that SCTP was triggering a WARN on socket destroy
> related to disabling sock timestamp.
>
> When SCTP accepts an association or peel one off, it copies sock flags
> but forgot to call net_enable_timestamp() if a packe
On 12/04/2015 12:14 PM, Marcelo Ricardo Leitner wrote:
> SCTP echoes a cookie o INIT ACK chunks that contains a timestamp, for
> detecting stale cookies. This cookie is echoed back to the server by the
> client and then that timestamp is checked.
>
> Thing is, if the listening socket is using pack
Hi Dave,
On Fri, Dec 4, 2015, at 21:06, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Fri, 04 Dec 2015 20:59:05 +0100
>
> > Yes, I agree, I am totally with you here. If generic offloading can be
> > realized by NICs I am totally with you that this should be the way to
> > go. I don't
On Fri, Dec 4, 2015 at 6:48 PM, Marcelo Ricardo Leitner
wrote:
> Hi Dmitry,
>
> Can you please test this patch?
> I'll re-post with proper subject if it works.
Still happening with the same stacks.
> ---8<---
>
> Dmitry Vyukov reported a use-after-free in the code expanded by the
> macro debug_
On Mon, Nov 30, 2015 at 11:15:23AM +0200, Michael S. Tsirkin wrote:
> We know vring num is a power of 2, so use &
> to mask the high bits.
>
> Signed-off-by: Michael S. Tsirkin
> ---
The generated code switches from DIV -> masking, source is clearer as well.
Tested-by: Venkatesh Srinivas
-- v
(no top posting please)
On 02/12/15 00:26, Marcin Wojtas wrote:
> Hi Florian,
>
> Can you please describe in more details, what would you expect from
> such special abstraction layer regarding buffer managers? I'd like to
> understand more of your expectations and evaluate possible work.
Well, s
On Fri, Dec 4, 2015 at 12:06 PM, David Miller wrote:
> From: Hannes Frederic Sowa
> Date: Fri, 04 Dec 2015 20:59:05 +0100
>
>> Yes, I agree, I am totally with you here. If generic offloading can be
>> realized by NICs I am totally with you that this should be the way to
>> go. I don't see that co
From: Joe Perches
Date: Fri, 04 Dec 2015 12:00:35 -0800
> On Fri, 2015-12-04 at 14:55 -0500, David Miller wrote:
>> From: Madalin Bucur
>> Date: Thu, 3 Dec 2015 15:49:43 +0200
>>
>> > @@ -0,0 +1,22 @@
>> > +menuconfig FSL_DPAA_ETH
>> > + tristate "DPAA Ethernet"
>> > + depends on FSL_SO
From: Hannes Frederic Sowa
Date: Fri, 04 Dec 2015 20:59:05 +0100
> Yes, I agree, I am totally with you here. If generic offloading can be
> realized by NICs I am totally with you that this should be the way to
> go. I don't see that coming in the next (small number of) years, so I
> don't see a r
On Fri, Dec 4, 2015, at 20:59, Hannes Frederic Sowa wrote:
> And then filling out those fields using the offsetof and sizeof of the
> headers, but this seemed to be very difficult a) because they use
> bitmasks (which of course could be converted) or in case of IPv6 a
> schema would have to be sp
From: Marcin Wojtas
Date: Thu, 3 Dec 2015 15:20:48 +0100
> During my work on mvneta driver I revised mvpp2, and it occurred that the
> initial version of Marvell Armada 375 SoC comprised bugs around
> DMA-unmapping in both ingress and egress paths - not all buffers were
> umapped in TX path and
On Fri, 2015-12-04 at 14:55 -0500, David Miller wrote:
> From: Madalin Bucur
> Date: Thu, 3 Dec 2015 15:49:43 +0200
>
> > @@ -0,0 +1,22 @@
> > +menuconfig FSL_DPAA_ETH
> > + tristate "DPAA Ethernet"
> > + depends on FSL_SOC && FSL_BMAN && FSL_QMAN && FSL_FMAN
> > + select PHYLIB
> > +
Hi Tom,
On Fri, Dec 4, 2015, at 19:28, Tom Herbert wrote:
> > I do know that, but fact is, the current drivers do it. I am concerned
> > about the amount of entropy in one single 16 bit field used to
> > distinguish flows. Flow labels fine and good, but if current hardware
> > does not support it,
Thanks a ton! David :)
On 12/4/2015 7:37 PM, David Miller wrote:
From: Salil Mehta
Date: Thu, 3 Dec 2015 12:17:52 +
This PATCH V7 addresses the TAB formatting comments by
Sergei Shtylyov. Missing TABs at some other palces have
also been corrected.
Series applied, thanks.
--
To unsubsc
From: Madalin Bucur
Date: Thu, 3 Dec 2015 15:49:43 +0200
> @@ -0,0 +1,22 @@
> +menuconfig FSL_DPAA_ETH
> + tristate "DPAA Ethernet"
> + depends on FSL_SOC && FSL_BMAN && FSL_QMAN && FSL_FMAN
> + select PHYLIB
> + select FSL_FMAN_MAC
I do not see the FSL_FMAN_MAC Kconfig symbol de
[...]
Please provide a sketch up for a protocol generic api that can tell
hardware where a inner protocol header starts that supports vxlan,
vxlan-gpe, geneve and ipv6 extension headers and knows which protocol is
starting at that point.
>>> BPF. Implementing protocol gene
On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote:
> From: Alexei Starovoitov
> Date: Fri, 4 Dec 2015 11:10:15 -0800
>
>> just don't generate random bpf programs with such shifts.
>
> Agreed, it is exactly the same as if the compiler emitted real cpu
> shift instructions with undefined behavior.
From: Herbert Xu
Date: Thu, 3 Dec 2015 20:41:29 +0800
> Thomas and Phil observed that under stress rhashtable insertion
> sometimes failed with EBUSY, even though this error should only
> ever been seen when we're under attack and our hash chain length
> has grown to an unacceptable level, even a
From: Salil Mehta
Date: Thu, 3 Dec 2015 12:17:52 +
> This PATCH V7 addresses the TAB formatting comments by
> Sergei Shtylyov. Missing TABs at some other palces have
> also been corrected.
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
From: Manish Chopra
Date: Thu, 3 Dec 2015 05:59:14 -0500
> @@ -124,8 +124,19 @@ struct qed_spq {
> dma_addr_t p_phys;
> struct qed_spq_entry*p_virt;
>
> - /* Used as index for completions (returns on EQ by FW) */
> - u16 echo_idx;
> +
From: Pravin Shelar
Date: Fri, 4 Dec 2015 10:49:37 -0800
> On Thu, Dec 3, 2015 at 2:41 AM, Jiri Benc wrote:
>> Fill the metadata correctly even when tunneling over IPv6. Also, check that
>> the provided metadata is of an address family that is supported by the
>> tunnel.
>>
>> Signed-off-by: Jir
From: Alexei Starovoitov
Date: Fri, 4 Dec 2015 11:10:15 -0800
> just don't generate random bpf programs with such shifts.
Agreed, it is exactly the same as if the compiler emitted real cpu
shift instructions with undefined behavior.
The creator of the BPF code in question is what should be fixe
On Fri, 2015-12-04 at 19:45 +0100, Gregory CLEMENT wrote:
> With this patch each CPU is associated with its own set of TX queues. In
> the same time the SKB received in mvneta_tx is bound to the queue
> associated to the CPU sending the data. Thanks to this the next IRQ will
> be received on the sa
On Fri, Dec 04, 2015 at 08:03:47PM +0100, Dmitry Vyukov wrote:
> > is it with some random seccomp program?
> > If normal libseccomp generates such programs than it needs to be fixed.
>
> Yes, it is with completely random seccomp program.
>
> >> Such shifts have undefined behavior according to C s
On Fri, Dec 04, 2015 at 01:23:33PM -0500, Dave Jones wrote:
> Trinity had aparently created a bpf program that upset things greatly.
> I guess I need to find a way to make it record those somewhere for replaying
> later.
>
> Alexei, any ideas ?
>
> Dave
>
>
> NMI watchdog: BUG: soft lock
On Fri, Dec 4, 2015 at 7:43 PM, Alexei Starovoitov
wrote:
> On Fri, Dec 04, 2015 at 12:17:08PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> UBSAN reports the following undefined behavior:
>>
>> UBSAN: Undefined behaviour in kernel/bpf/core.c:336:2
>> shift exponent 2835 is to large for 32-bit type
On Thu, Dec 3, 2015 at 2:41 AM, Jiri Benc wrote:
> Fill the metadata correctly even when tunneling over IPv6. Also, check that
> the provided metadata is of an address family that is supported by the
> tunnel.
>
> Signed-off-by: Jiri Benc
> ---
> v2: fixed unused variable warning when building wi
On Thu, Dec 3, 2015 at 2:41 AM, Jiri Benc wrote:
> Will be used also for ndo_fill_metadata_dst.
>
> Signed-off-by: Jiri Benc
Looks good.
Acked-by: Pravin B Shelar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More maj
This patch adds the support for the RSS related ethtool
function. Currently it only uses one entry in the indirection table which
allows associating an mvneta interface to a given CPU.
Signed-off-by: Gregory CLEMENT
Tested-by: Marcin Wojtas
---
drivers/net/ethernet/marvell/mvneta.c | 127 ++
Hi,
this series is the first step add RSS support on mvneta.
It will allow associating an ethernet interface to a given CPU through
RSS by using "ethtool -X ethX weight". Indeed, currently I only enable
one entry in the RSS lookup table. Even if it is not really RSS, it
allows to get back the irq
With this patch each CPU is associated with its own set of TX queues. In
the same time the SKB received in mvneta_tx is bound to the queue
associated to the CPU sending the data. Thanks to this the next IRQ will
be received on the same CPU allowing sending more data.
It will also allow to have a m
We enable the percpu interrupt for all the CPU and we just associate a
CPU to a few queue at the neta level. The mapping between the CPUs and
the queues is static. The queues are associated to the CPU module the
number of CPUs. However currently we only use on RX queue for a given
Ethernet port.
S
Instead of using the same default queue for all the port. Move it in the
port struct. It will allow have a different default queue for each port.
Signed-off-by: Gregory CLEMENT
---
drivers/net/ethernet/marvell/mvneta.c | 33 ++---
1 file changed, 18 insertions(+), 15
On Fri, Dec 04, 2015 at 12:17:08PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> UBSAN reports the following undefined behavior:
>
> UBSAN: Undefined behaviour in kernel/bpf/core.c:336:2
> shift exponent 2835 is to large for 32-bit type 'unsigned int'
> CPU: 1 PID: 14227 Comm: syzkaller_execu Not tain
> I do know that, but fact is, the current drivers do it. I am concerned
> about the amount of entropy in one single 16 bit field used to
> distinguish flows. Flow labels fine and good, but if current hardware
> does not support it, it does not help. Imagine containers with lots of
> applications,
1 - 100 of 180 matches
Mail list logo
