The series add the large receive offload (LRO) functions by hardware and
the ethtool functions to configure RX flows of HW LRO.
changes since v2:
- Add ndo_fix_features to prevent NETIF_F_LRO off while RX flow is programmed
- Rephrase the dts property is a capability if the hardware supports LRO
The codes add the large receive offload (LRO) functions by hardware as below:
1) PDMA has total four RX rings that one is the normal ring, and others can
be configured as LRO rings.
2) Only TCP/IP RX flows can be offloaded. The hardware can set four IP
addresses at most, if the destination IP
Add the dts property for the capability if the hardware supports LRO.
Signed-off-by: Nelson Chang
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt
b/Documentation/devicetree/bi
The codes add ethtool functions to set RX flows for HW LRO. Because the
HW LRO hardware can only recognize the destination IP of TCP/IP RX flows,
the ethtool command to add HW LRO flow is as below:
ethtool -N [devname] flow-type tcp4 dst-ip [ip_addr] loc [0~1]
Otherwise, cause the hardware can set
Hi Marcelo
On 9/13/16 2:57 AM, Marcelo wrote:
On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:
This is to use the generic interface snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Then snmp_seq_show and netstat_seq_show are sp
From: Eric Dumazet
When skb replaces another one in ooo queue, I forgot to also
update tp->ooo_last_skb as well, if the replaced skb was the last one
in the queue.
To fix this, we simply can re-use the code that runs after an insertion,
trying to merge skbs at the right of current skb.
This not
On Tue, 2016-09-13 at 22:13 -0700, Michael Ma wrote:
> I don't intend to install multiple qdisc - the only reason that I'm
> doing this now is to leverage MQ to workaround the lock contention,
> and based on the profile this all worked. However to simplify the way
> to setup HTB I wanted to use TX
(resend)
Thanks Florian for the review!
I will add ndo_fix_features hook in v2 to prevent the case that a user
wants to turn off NETIF_F_LRO but RX flow is programmed.
If any programmed RX flow exists, NETIF_F_LRO cannot be turned off.
-Original Message-
From: Florian Fainelli [mailto:f.f
(resend)
The description of the property as you said is more precise.
The property is a capability if the hardware supports LRO. I'll rephrase
the property description in v2.
Thanks Florian!
-Original Message-
From: Florian Fainelli [mailto:f.faine...@gmail.com]
Sent: Wednesday, Septembe
2016-09-13 22:13 GMT-07:00 Michael Ma :
> 2016-09-13 18:18 GMT-07:00 Eric Dumazet :
>> On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote:
>>
>>> If I understand correctly this is still to associate a qdisc with each
>>> ifb TXQ. How should I do this if I want to use HTB? I guess I'll need
>>> to
2016-09-13 18:18 GMT-07:00 Eric Dumazet :
> On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote:
>
>> If I understand correctly this is still to associate a qdisc with each
>> ifb TXQ. How should I do this if I want to use HTB? I guess I'll need
>> to divide the bandwidth of each class in HTB by th
On Tue, Sep 13, 2016 at 07:24:08PM +0200, Pablo Neira Ayuso wrote:
> On Tue, Sep 13, 2016 at 03:31:20PM +0200, Daniel Mack wrote:
> > Hi,
> >
> > On 09/13/2016 01:56 PM, Pablo Neira Ayuso wrote:
> > > On Mon, Sep 12, 2016 at 06:12:09PM +0200, Daniel Mack wrote:
> > >> This is v5 of the patch set t
On 9/13/16 10:00 PM, Lorenzo Colitti wrote:
> On Fri, Sep 9, 2016 at 2:23 PM, Lorenzo Colitti wrote:
>> RFC patch sent out as http://patchwork.ozlabs.org/patch/667892/ . This
>> achieves a fair bit of simplification with no or negligible
>> performance impact, because there was a lot of redundancy
On Fri, Sep 9, 2016 at 2:23 PM, Lorenzo Colitti wrote:
> RFC patch sent out as http://patchwork.ozlabs.org/patch/667892/ . This
> achieves a fair bit of simplification with no or negligible
> performance impact, because there was a lot of redundancy in the
> parameters that were passed in.
David,
From: Sean Wang
This cleans up the error path inside mtk_hw_init call, causing it able
to exit appropriately when something fails and also includes refactoring
mtk_cleanup call to make the partial logic reusable on the error path.
Signed-off-by: Sean Wang
---
drivers/net/ethernet/mediatek/mtk_
From: Sean Wang
add the protection of the race condition between
the reset process and hardware access happening
on the related callbacks.
Signed-off-by: Sean Wang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 36 +
drivers/net/ethernet/mediatek/mtk_eth_soc.h |
From: Sean Wang
Current driver only resets DMA used by descriptor rings which
can't guarantee it can recover all various kinds of fatal
errors, so the patch
1) tries to reset the underlying hardware resource from scratch on
Mediatek SoC required for ethernet running.
2) refactors code in order to
From: Sean Wang
grouping things related to the deinitialization of what
mtk_hw_init call does that help to be reused by the reset
process and the error path handling.
Signed-off-by: Sean Wang
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 15 +++
1 file changed, 11 insertions(+)
From: Sean Wang
struct mtk_eth has already contained struct regmap ethsys pointer
to the address range of the internal circuit reset, so we reuse it
to reset more internal blocks on ethernet hardware such as packet
processing engine (PPE) and frame engine (FE) instead of rstc which
deals with FE
From: Sean Wang
1) original driver only resets DMA used by descriptor rings
which can't guarantee it can recover all various kinds of fatal
errors, so the patch tries to reset the underlying hardware
resource from scratch on Mediatek SoC required for ethernet
running, including power, pin mux con
From: Sean Wang
introduce power domain control which the digital circuit of
the ethernet belongs to inside the flow of hardware initialization
and deinitialization which helps the entire ethernet hardware block
could restart cleanly and completely as being back to the initial
state when the whole
From: Sean Wang
the existing mtk_hw_init includes hardware and software
initialization inside so that it is slightly hard to reuse
them for the process of the reset recovery, so some splitting
is made here for keeping hardware initializing relevant thing
and the else such as IRQ registration and
On 9/12/16 12:01 PM, Mahesh Bandewar wrote:
> +struct sk_buff *ipvlan_l3_rcv(struct net_device *dev, struct sk_buff *skb,
> + u16 proto)
> +{
> + struct ipvl_addr *addr;
> + struct net_device *sdev;
> +
> + addr = ipvlan_skb_to_addr(skb, dev);
> + if (!add
On 9/13/16 3:05 AM, Marcelo wrote:
On Fri, Sep 09, 2016 at 02:33:58PM +0800, Jia He wrote:
This is to use the generic interface snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Signed-off-by: Jia He
---
net/ipv6/proc.c | 32 ++
Hi Marcelo
On 9/13/16 2:57 AM, Marcelo wrote:
On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:
This is to use the generic interface snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Then snmp_seq_show and netstat_seq_show are sp
Sure Dave, Will submit new patches with these changes.
Thanks
Raghu.
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Saturday, September 10, 2016 9:42 PM
> To: Vatsavayi, Raghu
> Cc: netdev@vger.kernel.org; Chickles, Derek; Burla, Satananda; Manlunas,
> Felix
On Tue, 2016-09-13 at 17:23 -0700, Michael Ma wrote:
> If I understand correctly this is still to associate a qdisc with each
> ifb TXQ. How should I do this if I want to use HTB? I guess I'll need
> to divide the bandwidth of each class in HTB by the number of TX
> queues for each individual HTB
On Tue, Sep 13, 2016 at 02:48:38PM -0700, Olof Johansson wrote:
> The platform is old, very few users and I lack bandwidth to keep after
> it these days.
>
> Mark the base platform as well as the drivers as orphans, patches have
> been flowing through the fallback maintainers for a while already.
2016-09-13 17:09 GMT-07:00 Eric Dumazet :
> On Tue, 2016-09-13 at 16:30 -0700, Michael Ma wrote:
>
>> The RX queue number I found from "ls /sys/class/net/eth0/queues" is
>> 64. (is this the correct way of identifying the queue number on NIC?)
>> I setup ifb with 24 queues which is equal to the TX q
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 10:41:12PM +, Rustad, Mark D wrote:
That said, I can see that you have tried to keep the original code path
pretty much intact. I would note that you introduced rcu calls into the
!bpf
path that would never have been done before. While t
On Tue, 2016-09-13 at 16:30 -0700, Michael Ma wrote:
> The RX queue number I found from "ls /sys/class/net/eth0/queues" is
> 64. (is this the correct way of identifying the queue number on NIC?)
> I setup ifb with 24 queues which is equal to the TX queue number of
> eth0 and also the number of CPU
On 09/13/16 at 11:25am, David Miller wrote:
>
> Just to be clear, I did actually apply this v2 of the patch
> rather than the initial version.:)
Thanks a lot!
On Tue, Sep 13, 2016 at 10:41:12PM +, Rustad, Mark D wrote:
> That said, I can see that you have tried to keep the original code path
> pretty much intact. I would note that you introduced rcu calls into the !bpf
> path that would never have been done before. While that should be ok, I
> would
Rustad, Mark D :
> Alexei Starovoitov wrote:
[...]
> > the point that it's only used virtualized, since PCI (not PCIE) have
> > been long dead.
>
> My point is precisely the opposite. It is a real device, it exists in real
> systems and it is used in those systems. I worked on embedded systems t
On Tue, 2016-09-13 at 15:59 -0700, Michael Ma wrote:
> Hi -
>
> We currently use mqprio on ifb to work around the qdisc root lock
> contention on the receiver side. The problem that we found was that
> queue_mapping is already set when redirecting from ingress qdisc to
> ifb (based on RX selection
Did you get my message?
Hi -
We currently use mqprio on ifb to work around the qdisc root lock
contention on the receiver side. The problem that we found was that
queue_mapping is already set when redirecting from ingress qdisc to
ifb (based on RX selection, I guess?) so the TX queue selection is not
based on priority.
Create an address for sendmsg() to bind unbound socket with rather than
using a completely blank address otherwise the transport socket creation
will fail because it will try to use address family 0.
We use the address family specified in the protocol argument when the
AF_RXRPC socket was created
There are two places that want to transmit a packet in response to one just
received and manually pick the address to reply to out of the sk_buff.
Make them use rxrpc_extract_addr_from_skb() instead so that IPv6 is handled
automatically.
Signed-off-by: David Howells
---
net/rxrpc/local_event.c
Pass 0 as the protocol argument when creating the transport socket rather
than IPPROTO_UDP.
Signed-off-by: David Howells
---
net/rxrpc/local_object.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rxrpc/local_object.c b/net/rxrpc/local_object.c
index 782b9adf67cb
Add IPv6 support to AF_RXRPC. With this, AF_RXRPC sockets can be created:
service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET6);
instead of:
service = socket(AF_RXRPC, SOCK_DGRAM, PF_INET);
The AFS filesystem doesn't support IPv6 at the moment, though, since that
requires upgrades t
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-rewrite-20160913-2
David
---
David Howells (4):
rxrpc: Create an address for sendmsg() to bind unbound socket with
rxrpc: Don't specify protocol to when creating transport socket
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 07:14:27PM +, Rustad, Mark D wrote:
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote:
Alexei Starovoitov wrote:
I've looked through qemu and it appears only emulate e1k and tg3.
The latter is s
On Tue, 2016-09-13 at 07:23 +, Y.B. Lu wrote:
> >
> >
> > -Original Message-
> > From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> > ow...@vger.kernel.org] On Behalf Of Scott Wood
> > Sent: Tuesday, September 13, 2016 7:25 AM
> > To: Y.B. Lu; linux-...@vger.kernel.org; ulf.
Allow tx_winsize to grow when the ACK info packet shows a larger receive
window at the other end rather than only permitting it to shrink.
Signed-off-by: David Howells
---
net/rxrpc/input.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/input.c b/net/rx
The preallocated call buffer holds a ref on the calls within that buffer.
The ref was being released in the wrong place - it worked okay for incoming
calls to the AFS cache manager service, but doesn't work right for incoming
calls to a userspace service.
Instead of releasing an extra ref service
Peer records created for incoming connections weren't getting their hash
key set. This meant that incoming calls wouldn't see more than one DATA
packet - which is not a problem for AFS CM calls with small request data
blobs.
Signed-off-by: David Howells
---
net/rxrpc/peer_object.c |2 +-
1
The IDLE ACK packet should use the rxrpc_idle_ack_delay setting when the
timer is set for it.
Signed-off-by: David Howells
---
net/rxrpc/call_event.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c
index 2b976e789562..614320
call->rx_winsize should be initialised to the sysctl setting and the sysctl
setting should be limited to the maximum we want to permit. Further, we
need to place this in the ACK info instead of the sysctl setting.
Furthermore, discard the idea of accepting the subpackets of a jumbo packet
that li
skb->len should be used rather than skb->data_len when referring to the
amount of data in a packet. This will only cause a malfunction in the
following cases:
(1) We receive a jumbo packet (validation and splitting both are wrong).
(2) We see if there's extra ACK info in an ACK packet (we thin
Add a missing unlock in rxrpc_call_accept() in the path taken if there's no
call to wake up.
Signed-off-by: David Howells
---
net/rxrpc/call_accept.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index b8acec0d59
rxrpc_recvmsg() needs to make sure that the call it has just been
processing gets requeued for further attention if the buffer has been
filled and there's more data to be consumed. The softirq producer only
queues the call and wakes the socket if it fills the first slot in the
window, so userspace
Adjust the call ref tracepoint to show references held on a call by the
kernel API separately as much as possible and add an additional trace to at
the allocation point from the preallocation buffer for an incoming call.
Note that this doesn't show the allocation of a client call for the kernel
se
We need to wake up the sender when Tx window rotation due to an incoming
ACK makes space in the buffer otherwise the sender is liable to just hang
endlessly.
This problem isn't noticeable if the Tx phase transfers no more than will
fit in a single window or the Tx window rotates fast enough that i
el.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-rewrite-20160913-1
David
---
David Howells (10):
rxrpc: Make sure we initialise the peer hash key
rxrpc: Add missing wakeup on Tx window rotation
rxrpc: The IDLE ACK packet should use rxrpc_idle_ack_delay
Hi Jarod,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Jarod-Wilson/net-centralize-net_device-min-max-MTU-checking/20160913-042130
config: mips-xway_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
On Tue, Sep 13, 2016 at 07:14:27PM +, Rustad, Mark D wrote:
> Alexei Starovoitov wrote:
>
> >On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote:
> >>Alexei Starovoitov wrote:
> >>
> >>>I've looked through qemu and it appears only emulate e1k and tg3.
> >>>The latter is still used
The platform is old, very few users and I lack bandwidth to keep after
it these days.
Mark the base platform as well as the drivers as orphans, patches have
been flowing through the fallback maintainers for a while already.
Signed-off-by: Olof Johansson
---
Jean, Dave,
I was hoping to have Mic
Shuah Khan wrote:
Is watchdog-simple a test or a sample/example? I thought this
is an example, and planning to move that under examples?
If this is a test, I will re-do the patch to include it.
I guess it's really just a sample.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qua
On Tue, Sep 13, 2016 at 7:08 AM, Lance Richardson wrote:
> The ovs kernel data path currently defers the execution of all
> recirc actions until stack utilization is at a minimum.
> This is too limiting for some packet forwarding scenarios due to
> the small size of the deferred action FIFO (10 en
On 09/13/2016 02:33 PM, Timur Tabi wrote:
> Shuah Khan wrote:
>> Remove watchdog-test from Makefile to move the test to selftests.
>>
>> Add Makefile and .gitignore to for watchdog-test. watchdog-test will
>
> to for?
Thanks - will fix that.
>
>> not be run as part of selftests suite and will n
Shuah Khan wrote:
Remove watchdog-test from Makefile to move the test to selftests.
Add Makefile and .gitignore to for watchdog-test. watchdog-test will
to for?
not be run as part of selftests suite and will not be included in
install targets. It can be built separately for now.
Signed-off
On Tue, 2016-09-13 at 20:18 +, Rustad, Mark D wrote:
> Greg wrote:
>
> > Someday Linux will be a modern OS that just includes IPV6 and forces a
> > config option to NOT have it.
> >
> > That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
> > is nuts.
> >
> >
>
> Better
Remove vDSO from Makefile to move the to selftests. Update vDSO Makefile
to work under selftests. vDSO will not be run as part of selftests suite
and will not be included in install targets. They can be built separately
for now.
Signed-off-by: Shuah Khan
---
Documentation/Makefile
Move dnotify_test.c, Makefile, and .gitignore from Documentation/filesystems
to selftests/filesystems.
Remove filesystems build target from Documentation/Makefile and update
selftests/filesystems/Makefile to work under selftests. dnotify_test will
not be run as part of selftests suite and will not
Remove ia64 from Makefile to move the test to selftests.
Update ia64 Makefile to work under selftests. ia64 will not be run as part
of selftests suite and will not be included in install targets. They can be
built separately for now.
The original Makefile built this test on all archirectures and
Remove watchdog-test from Makefile to move the test to selftests.
Add Makefile and .gitignore to for watchdog-test. watchdog-test will
not be run as part of selftests suite and will not be included in
install targets. It can be built separately for now.
Signed-off-by: Shuah Khan
---
Documentat
Greg wrote:
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
Better wait until everyone at least *has* IPv6! I have yet to have IPv6
deployed on any of my
Move runnable code (tests) from Documentation to selftests and update
Makefiles to work under selftests.
Jon Corbet and I discussed this in an email thread and as per that
discussion, this patch series moves all the tests that are under the
Documentation directory to selftests. There is more runna
Move prctl tests from Documentation/prctl to selftests/prctl.
Remove prctl from Makefile to move the test. Update prctl Makefile to work
under selftests. prctl will not be run as part of selftests suite and will
not be included in install targets. They can be built separately for now.
Signed-off-
Remove ptp from Makefile to move the test to selftests. Update ptp Makefile
to work under selftests. ptp will not be run as part of selftests suite and
will not be included in install targets. They can be built separately for
now.
Signed-off-by: Shuah Khan
---
Documentation/Makefile
> This patch series removes duplicate code from
> iw_cxgb4 and cxgbit by adding common function
> definitions in libcxgb.
>
> Please review.
>
> Thanks
> Varun
>
> Varun Prakash (11):
> libcxgb,iw_cxgb4,cxgbit: add cxgb_get_4tuple()
> libcxgb,iw_cxgb4,cxgbit: add cxgb_find_route()
> libcxg
Hi Dave,
We found a few more issues, I'm sending you small fixes here. The diffstat
would be even shorter, but one of Felix's patches has to move about 30 lines
of code, which makes it seem much bigger than it really is.
Let me know if there's any problem.
Thanks,
johannes
The following chang
On 16-09-13 12:20 PM, Cong Wang wrote:
On Mon, Sep 12, 2016 at 4:07 PM, Jamal Hadi Salim wrote:
From: Jamal Hadi Salim
With the batch changes that translated transient actions into
a temporary list lost in the translation was the fact that
tcf_action_destroy() will eventually delete the actio
Alexei Starovoitov wrote:
On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote:
Alexei Starovoitov wrote:
I've looked through qemu and it appears only emulate e1k and tg3.
The latter is still used in the field, so the risk of touching
it is higher.
I have no idea what makes you
> F:drivers/net/dsa/
>
> Other than that, LGTM
I was a bit hesitant to go that far. We have individual entries for
b53 and mv88e6xxx, but not for bcm_sf2. But O.K, v2 on the way.
Andrew
On 13/09/2016 21:07, Andrew Lunn wrote:
>> Since the former alternative is prefered, we may want to remove the
>> latter soon from DSA. If this phy_port_map is needed for that case, it'd
>> be preferable not to add it.
>
> O.K, so maybe we should solve it the device tree way:
>
>
>&mdi
> Since the former alternative is prefered, we may want to remove the
> latter soon from DSA. If this phy_port_map is needed for that case, it'd
> be preferable not to add it.
O.K, so maybe we should solve it the device tree way:
&mdio0 {
phy_port1: phy@0 {
On 09/13/2016 12:00 PM, Andrew Lunn wrote:
> The core distributed switch architecture code currently does not have
> a MAINTAINERS entry, which results in some contributions not landing
> in the right peoples inbox.
>
> Signed-off-by: Andrew Lunn
> ---
> MAINTAINERS | 7 +++
> 1 file changed
The core distributed switch architecture code currently does not have
a MAINTAINERS entry, which results in some contributions not landing
in the right peoples inbox.
Signed-off-by: Andrew Lunn
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
i
On Tue, 2016-09-13 at 20:19 +0300, Cyrill Gorcunov wrote:
> In criu we are actively using diag interface to collect sockets
> present in the system when dumping applications. And while for
> unix, tcp, udp[lite], packet, netlink it works as expected,
> the raw sockets do not have. Thus add it.
>
>
On 09/13/2016 06:54 AM, Nelson Chang wrote:
> Add the configuration of HW LRO in the binding document.
>
> Signed-off-by: Nelson Chang
> ---
> Documentation/devicetree/bindings/net/mediatek-net.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/
On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote:
> Alexei Starovoitov wrote:
>
> >I've looked through qemu and it appears only emulate e1k and tg3.
> >The latter is still used in the field, so the risk of touching
> >it is higher.
>
> I have no idea what makes you think that e1k i
Alexei Starovoitov wrote:
I've looked through qemu and it appears only emulate e1k and tg3.
The latter is still used in the field, so the risk of touching
it is higher.
I have no idea what makes you think that e1k is *not* "used in the field".
I grant you it probably is used more virtualiz
On 09/13/2016 06:54 AM, Nelson Chang wrote:
> The codes add ethtool functions to set RX flows for HW LRO. Because the
> HW LRO hardware can only recognize the destination IP of TCP/IP RX flows,
> the ethtool command to add HW LRO flow is as below:
> ethtool -N [devname] flow-type tcp4 dst-ip [ip_ad
On 09/13/2016, 05:35 PM, Tejun Heo wrote:
> Hello,
>
> On Sat, Sep 10, 2016 at 11:33:48AM +0200, Dmitry Vyukov wrote:
>> Hit the WARNING with the patch. It showed "Showing busy workqueues and
>> worker pools:" after the WARNING, but then no queue info. Was it
>> already destroyed and removed from
On 09/13/2016 11:07 AM, John Crispin wrote:
>
>
> On 13/09/2016 19:09, Florian Fainelli wrote:
>> On 09/13/2016 08:59 AM, Andrew Lunn wrote:
Hi Andrew,
this function does indeed duplicate the functionality of
phy_ethtool_get_eee() with the small difference, that e->eee_active
On 13/09/2016 19:09, Florian Fainelli wrote:
> On 09/13/2016 08:59 AM, Andrew Lunn wrote:
>>> Hi Andrew,
>>>
>>> this function does indeed duplicate the functionality of
>>> phy_ethtool_get_eee() with the small difference, that e->eee_active is
>>> also set which phy_ethtool_get_eee() does not se
sctp_outq_flush return value is meaningless now, this patch is
to make sctp_outq_flush return void, as well as sctp_outq_fail
and sctp_outq_uncork.
Signed-off-by: Xin Long
---
include/net/sctp/structs.h | 4 ++--
net/sctp/outqueue.c| 19 +++
net/sctp/sm_sideeffect.c |
As David and Marcelo's suggestion, ENOMEM err shouldn't return back to
user in transmit path. Instead, sctp's retransmit would take care of
the chunks that fail to send because of ENOMEM.
This patch is only to do some release job when alloc_skb fails, not to
return ENOMEM back any more.
Besides,
Last patch "sctp: do not return the transmit err back to sctp_sendmsg"
made sctp_primitive_SEND return err only when asoc state is unavailable.
In this case, chunks are not enqueued, they have no chance to be freed if
we don't take care of them later.
This Patch is actually to revert commit 1cd4d5
Every time when sctp calls sctp_outq_flush, it sends out the chunks of
control queue, retransmit queue and data queue. Even if some trunks are
failed to transmit, it still has to flush all the transports, as it's
the only chance to clean that transmit_list.
So the latest transmit error here should
Once a chunk is enqueued successfully, sctp queues can take care of it.
Even if it is failed to transmit (like because of nomem), it should be
put into retransmit queue.
If sctp report this error to users, it confuses them, they may resend
that msg, but actually in kernel sctp stack is in charge o
Data Chunks are only sent by sctp_primitive_SEND, in which sctp checks
the asoc's state through statetable before calling sctp_outq_tail. So
there's no need to check the asoc's state again in sctp_outq_tail.
Besides, sctp_do_sm is protected by lock_sock, even if sending msg is
interrupted by timer
This patchset is to improve the transmit err process and also fix some
issues.
After this patchset, once the chunks are enqueued successfully, even
if the chunks fail to send out, no matter because of nodst or nomem,
no err retruns back to users any more. Instead, they are taken care
of by retrans
On Tue, Sep 13, 2016 at 10:37:32AM -0700, Eric Dumazet wrote:
> On Tue, 2016-09-13 at 10:13 -0700, Alexei Starovoitov wrote:
>
> > I'm afraid the point 'only for debugging' still didn't make it across.
> > xdp+e1k is for development (and debugging) of xdp-type of bpf
> > programs and _not_ for deb
>
> I also don't see an issue with this patch, btw.
>
> Xin, you may want to add more/such details to the changelog, specially
> about the timer versus primitive handling.
>
OK, I will post v2 of this patchset.
On Tue, Sep 13, 2016 at 10:13 AM, Alexei Starovoitov
wrote:
> On Tue, Sep 13, 2016 at 09:21:47AM -0700, Tom Herbert wrote:
>> On Mon, Sep 12, 2016 at 6:28 PM, Alexei Starovoitov
>> wrote:
>> > On Mon, Sep 12, 2016 at 05:03:25PM -0700, Tom Herbert wrote:
>> >> On Mon, Sep 12, 2016 at 4:46 PM, Eric
On Tue, 2016-09-13 at 10:13 -0700, Alexei Starovoitov wrote:
> I'm afraid the point 'only for debugging' still didn't make it across.
> xdp+e1k is for development (and debugging) of xdp-type of bpf
> programs and _not_ for debugging of xdp itself, kernel or anything else.
> The e1k provided interf
On Tue, Sep 13, 2016 at 03:31:20PM +0200, Daniel Mack wrote:
> Hi,
>
> On 09/13/2016 01:56 PM, Pablo Neira Ayuso wrote:
> > On Mon, Sep 12, 2016 at 06:12:09PM +0200, Daniel Mack wrote:
> >> This is v5 of the patch set to allow eBPF programs for network
> >> filtering and accounting to be attached
1 - 100 of 227 matches
Mail list logo
