On 04/18/2018 06:26 AM, Michael Schmitz wrote:
> The Asix Electronics PHY found on the X-Surf 100 Amiga Zorro network
> card by Individual Computers is buggy, and needs the reset bit toggled
> as workaround to make a PHY soft reset succed.
^^
rhashtable_walk_prev() returns the object returned by
the previous rhashtable_walk_next(), providing it is still in the
table (or was during this grace period).
This works even if rhashtable_walk_stop() and rhashtable_talk_start()
have been called since the last rhashtable_walk_next().
If there ha
If the sequence:
obj = rhashtable_walk_next(iter);
rhashtable_walk_stop(iter);
rhashtable_remove_fast(ht, &obj->head, params);
rhashtable_walk_start(iter);
races with another thread inserting or removing
an object on the same hash chain, a subsequent
rhashtable_walk_next() is not gu
When a walk of an rhashtable is interrupted with rhastable_walk_stop()
and then rhashtable_walk_start(), the location to restart from is based
on a 'skip' count in the current hash chain, and this can be incorrect
if insertions or deletions have happened. This does not happen when
the walk is not
The documentation claims that when rhashtable_walk_start_check()
detects a resize event, it will rewind back to the beginning
of the table. This is not true. We need to set ->slot and
->skip to be zero for it to be true.
Acked-by: Herbert Xu
Signed-off-by: NeilBrown
---
lib/rhashtable.c |
grow_decision and shink_decision no longer exist, so remove
the remaining references to them.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/lin
Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so
remove the comments which suggest that they do.
Signed-off-by: NeilBrown
---
include/linux/rhashtable.h |3 ---
lib/rhashtable.c |3 ---
2 files changed, 6 deletions(-)
diff --git a/include/linux/rhashtable.h b
[[ I mistyped linux-kernel the first time I sent these, so
resending. Please reply to this set. Sorry - neilb ]]
Some of these have been posted before and a couple
received an Ack from Herbert, but haven't appeared in any git tree
yet.
Another (the first) has been sent but received no ack.
Hi,
let me revive this old thread...
On Mon, 2018-03-26 at 11:16 -0700, John Fastabend wrote:
> On 03/26/2018 10:30 AM, Cong Wang wrote:
> > On Sat, Mar 24, 2018 at 10:25 PM, John Fastabend
> > wrote:
> > > After the qdisc lock was dropped in pfifo_fast we allow multiple
> > > enqueue threads an
On Fri, Nov 17, 2017 at 4:06 AM, Jakub Kicinski
wrote:
> From: John Hurley
>
> Pass information to the match offload on whether or not the repr is the
> ingress or egress dev. Only accept tunnel matches if repr is the egress dev.
>
> This means rules such as the following are successfully offload
Hi Michael,
On Wed, Apr 18, 2018 at 12:35 AM, Michael Schmitz wrote:
> On Wed, Apr 18, 2018 at 1:53 AM, Geert Uytterhoeven
> wrote:
>> On Tue, Apr 17, 2018 at 12:04 AM, Michael Schmitz
>> wrote:
>>> Add platform device driver to populate the ax88796 platform data from
>>> information provided
Hi,
On Tue, 17 Apr 2018, Florian Westphal wrote:
> Dominique Martinet wrote:
>
> [ CC Jozsef ]
>
> > Could it have something to do with the way I setup the connection?
> > I don't think the "both remotes call connect() with carefully selected
> > source/dest port" is a very common case..
> >
Jozsef Kadlecsik wrote on Wed, Apr 18, 2018:
> Yes, the state transition is wrong for simultaneous open, because the
> tcp_conntracks table is not (cannot be) smart enough. Could you verify the
> next untested patch?
Thanks for the patch; I'll give it a try (probably won't make it today
so will
PPv2 TX/RX descriptors uses 40bits DMA addresses, but 41 bits masks were
used (GENMASK_ULL(40, 0)).
This commit fixes that by using the correct mask.
Fixes: e7c5359f2eed ("net: mvpp2: introduce PPv2.2 HW descriptors and adapt
accessors")
Signed-off-by: Maxime Chevallier
---
drivers/net/etherne
Wed, Apr 11, 2018 at 09:13:52PM CEST, sridhar.samudr...@intel.com wrote:
>On 4/11/2018 8:51 AM, Jiri Pirko wrote:
>> Tue, Apr 10, 2018 at 08:59:48PM CEST, sridhar.samudr...@intel.com wrote:
>> > This provides a generic interface for paravirtual drivers to listen
>> > for netdev register/unregister/
The JIT compiler emits ia32 bit instructions. Currently, It supports
eBPF only. Classic BPF is supported because of the conversion by BPF core.
Almost all instructions from eBPF ISA supported except the following:
BPF_ALU64 | BPF_DIV | BPF_K
BPF_ALU64 | BPF_DIV | BPF_X
BPF_ALU64 | BPF_MOD | BPF_K
Dominique Martinet wrote on Wed, Apr 18, 2018:
> Jozsef Kadlecsik wrote on Wed, Apr 18, 2018:
> > Yes, the state transition is wrong for simultaneous open, because the
> > tcp_conntracks table is not (cannot be) smart enough. Could you verify the
> > next untested patch?
>
> Thanks for the patch
> > Having dev-addr stored in devices_addrs, in get_phy_c45_ids(), when
> > probing the identifiers, dev-addr can be extracted from devices_addrs
> > and probed if devices_addrs[current_identifier] is not 0.
>
> I must clearly be missing something, but why are you introducing all these
> conditi
On Wed, Apr 18, 2018 at 05:31:18PM +0800, Wang YanQing wrote:
> The JIT compiler emits ia32 bit instructions. Currently, It supports
> eBPF only. Classic BPF is supported because of the conversion by BPF core.
>
> Almost all instructions from eBPF ISA supported except the following:
> BPF_ALU64 |
ACS Feature is currently enabled for GMAC >= 4 but the llc_snap status
is never checked in descriptor rx_status callback. This will cause
stmmac to always strip packets even that ACS feature is already
stripping them.
Lets be safe and disable the ACS feature for GMAC >= 4 and always strip
the pack
This patch enables arm64 platform support for the HINIC driver.
Signed-off-by: Zhao Chen
---
drivers/net/ethernet/huawei/hinic/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/Kconfig
b/drivers/net/ethernet/huawei/hinic/Kconfig
index
The goal of this series is to improve UDP performance in the RX path, that
got worse when spectre/meltdown mithigations were introduced.
The main idea is to move almost entirely the cost of skb handling from the
receiver process context into the BH processing, leveraging, for small
packets, a new
This changeset extends the idea behind commit c8c8b127091b ("udp:
under rx pressure, try to condense skbs"), trading more BH cpu
time and memory bandwidth to decrease the load on the user space
receiver.
At boot time we allocate a limited amount of skbs with small
data buffer, storing them in per
This commit moves the kfree_skb() call on queue full event from the
ipv4/ipv6 caller into __udp_enqueue_schedule_skb(), cleaning up the
code and avoid referencing the skb after that __udp_enqueue_schedule_skb()
completes, so that we can modify the skb ptr itself into the latter
function.
Signed-of
On Wed, 18 Apr 2018, Dominique Martinet wrote:
> Dominique Martinet wrote on Wed, Apr 18, 2018:
> > Jozsef Kadlecsik wrote on Wed, Apr 18, 2018:
> > > Yes, the state transition is wrong for simultaneous open, because the
> > > tcp_conntracks table is not (cannot be) smart enough. Could you verify
On 18/04/2018 7:29 AM, Nikita V. Shirokov wrote:
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for mlx4 driver we will just calculate packet's le
From: Colin Ian King
Trivial fix to spelling mistake
Signed-off-by: Colin Ian King
---
net/caif/chnl_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 53ecda10b790..13e2ae6be620 100644
--- a/net/caif/chnl_net.c
+++ b/net/c
On Tue, 2018-04-17 at 16:00 -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Segmentation offload reduces cycles/byte for large packets by
> amortizing the cost of protocol stack traversal.
>
> This patchset implements GSO for UDP. A process can concatenate and
> submit multiple datag
Jozsef Kadlecsik wrote on Wed, Apr 18, 2018:
> Thanks for the testing! One more line is required, however: we have to get
> the assured bit set for the connection, see the new patch below.
I think it actually was better before. If I understand things correctly
at this point (when we get in the ca
On Wed, 18 Apr 2018, Dominique Martinet wrote:
> Jozsef Kadlecsik wrote on Wed, Apr 18, 2018:
> > Thanks for the testing! One more line is required, however: we have to get
> > the assured bit set for the connection, see the new patch below.
>
> I think it actually was better before. If I unders
On 04/18/2018 04:56 AM, Stephen Hemminger wrote:
> This may already be fixed.
>
> Begin forwarded message:
>
> Date: Wed, 18 Apr 2018 01:52:59 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: step...@networkplumber.org
> Subject: [Bug 199429] New: smc_shutdown(net/smc/af_smc.c) has a UAF
From: Colin Ian King
Rename several macros that contain mispellings of UNKNOWN
Signed-off-by: Colin Ian King
---
drivers/net/wireless/ralink/rt2x00/rt2800.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800.h
b/drive
On Wed, Apr 18, 2018 at 12:47:50PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Rename several macros that contain mispellings of UNKNOWN
>
> Signed-off-by: Colin Ian King
Acked-by: Stanislaw Gruszka
This RFC patch¹ is an attempt to add multicast querier per VLAN support
to a VLAN aware bridge. I'm posting it as RFC for now since non-VLAN
aware bridges are not handled, and one of my questions is if that is
complexity we need to continue supporting?
>From what I understand, multicast join/repo
Avoid clearing xdp_frame area if this was already done by prevous
invocations of bpf_xdp_adjust_head.
The xdp_adjust_head helper can be called multiple times by the
bpf_prog. If increasing the packet header size (with a negative
offset), kernel must assume bpf_prog store valuable information here
This is a followup to fix commit:
6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on page reuse")
Posting as RFC, as I want Daniel to review this before it goes in, as
Daniel usually have smarter/brighter ideas of howto solve this in a
more optimal manor?
---
Jesper Dangaard Brouer
If combining xdp_adjust_head and xdp_adjust_meta, then it is possible
to make data_meta overlap with area used by xdp_frame. And another
invocation of xdp_adjust_head can then clear that area, due to
clearing of xdp_frame area.
The easiest solution I found was to simply not allow
xdp_buff->data_m
> +
> +/**
> + * asix_soft_reset - software reset the PHY via BMCR_RESET bit
> + * @phydev: target phy_device struct
> + *
> + * Description: Perform a software PHY reset using the standard
> + * BMCR_RESET bit and poll for the reset bit to be cleared.
> + * Toggle BMCR_RESET bit off to accomodate
On Wed, Apr 18, 2018 at 05:10:45PM +1200, Michael Schmitz wrote:
> All,
>
> just noticed belatedly that the Makefile hunk of patch 9 does no
> longer apply cleanly in 4.17-rc1, sorry. My series was based on 4.16.
> I'll resend that one, OK?
Hi Michael
You should be based on DaveM net-next tree:
On Wed, Apr 18, 2018 at 09:38:47AM +, Vicenţiu Galanopulo wrote:
>
>
> > > Having dev-addr stored in devices_addrs, in get_phy_c45_ids(), when
> > > probing the identifiers, dev-addr can be extracted from devices_addrs
> > > and probed if devices_addrs[current_identifier] is not 0.
> >
> > I
I went through the patch set and the code looks fine- it extends existing
infra for TCP/GSO to UDP.
One thing that was not clear to me about the API: shouldn't UDP_SEGMENT
just be automatically determined in the stack from the pmtu? Whats
the motivation for the socket option for this? also AIUI t
On Wed, Apr 18, 2018 at 8:43 AM, Or Gerlitz wrote:
> On Fri, Nov 17, 2017 at 4:06 AM, Jakub Kicinski
> wrote:
>> From: John Hurley
>>
>> Pass information to the match offload on whether or not the repr is the
>> ingress or egress dev. Only accept tunnel matches if repr is the egress dev.
>>
>> T
On 18/04/18 15:07, Joachim Nilsson wrote:
This RFC patch¹ is an attempt to add multicast querier per VLAN support
to a VLAN aware bridge. I'm posting it as RFC for now since non-VLAN
aware bridges are not handled, and one of my questions is if that is
complexity we need to continue supporting?
On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> Hi Rahul,
> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> > On production servers running variety of workloads over time, kernel
> > panic can happen sporadically after days or even months. It is
> > important to collect
On 04/18/2018 06:29 AM, Nikita V. Shirokov wrote:
> In this patch series i'm add new bpf helper which allow to manupulate
> xdp's data_end pointer. right now only "shrinking" (reduce packet's size
> by moving pointer) is supported (and i see no use case for "growing").
> Main use case for such help
On 04/17/2018 07:28 PM, Andrey Ignatov wrote:
> v1->v2:
> - add new types to bpftool-cgroup man page;
> - add new types to bash completion for bpftool;
> - don't add types that should not be in bpftool cgroup.
>
> Add support for various BPF prog types and attach types that have been
> added to ke
> If I look at the patch I think it should call kszphy_config_init() not
> _reset()
> in the resume function:
>
>
> @@ -715,8 +723,14 @@ static int kszphy_suspend(struct phy_device *phydev)
>
> static int kszphy_resume(struct phy_device *phydev)
> {
> + int ret;
> +
> genphy_resume(
On 04/17/2018 04:25 AM, Wang Sheng-Hui wrote:
> The program run against loopback interace "lo", not "eth0".
> Correct the comment.
>
> Signed-off-by: Wang Sheng-Hui
Applied to bpf-next, thanks Wang!
On 04/17/2018 04:08 PM, Jesper Dangaard Brouer wrote:
> The variable rec_i contains an XDP action code not an error.
> Thus, using err2str() was wrong, it should have been action2str().
>
> Signed-off-by: Jesper Dangaard Brouer
Applied to bpf-next, thanks Jesper!
On Tue, 17 Apr 2018 21:29:42 -0700
"Nikita V. Shirokov" wrote:
> w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
> well (only "decrease" of pointer's location is going to be supported).
> changing of this pointer will change packet's size.
> for generic XDP we need to ref
On 04/18/2018 04:46 AM, Jakub Kicinski wrote:
> From: Quentin Monnet
>
> bpftool uses hexadecimal values when it dumps map contents:
>
> # bpftool map dump id 1337
> key: ff 13 37 ff value: a1 b2 c3 d4 ff ff ff ff
> Found 1 element
>
> In order to lookup or update values with bpfto
Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote:
>Account for operational state when determining port linkup state,
>as per Documentation/networking/operstates.txt.
Could you please point me to the exact place in the document where this
is suggested?
>
>Signed-off-by: Geo
On Wed, Apr 18, 2018 at 09:34:16AM +0800, Chris Ruehl wrote:
> Hello,
>
> I like to get your heads up at a regression introduced in 4.9.94
> commitment lead to a kernel ops and make the network unusable on my MX6DL
> customized board.
>
> Race condition resume is called on startup and the phy not
Hi Dave,
On Mon, Apr 16, 2018 at 11:16 PM, David Miller wrote:
> From: jassisinghb...@gmail.com
> Date: Mon, 16 Apr 2018 12:52:16 +0530
>
>> From: Jassi Brar
>>
>> Enable TX-irq as well during ndo_open() as we can not count upon
>> RX to arrive early enough to trigger the napi. This patch is cri
On Wed, Apr 18, 2018 at 02:56:01PM +0200, Andrew Lunn wrote:
> On Wed, Apr 18, 2018 at 09:34:16AM +0800, Chris Ruehl wrote:
> > Hello,
> >
> > I like to get your heads up at a regression introduced in 4.9.94
> > commitment lead to a kernel ops and make the network unusable on my MX6DL
> > customiz
On Wed, Apr 18, 2018 at 03:31:57PM +0300, Nikolay Aleksandrov wrote:
> On 18/04/18 15:07, Joachim Nilsson wrote:
> > - First of all, is this patch useful to anyone
> Obviously to us as it's based on our patch. :-)
> We actually recently discussed what will be needed to make it acceptable to
> upst
On 18/04/18 16:07, Joachim Nilsson wrote:
> On Wed, Apr 18, 2018 at 03:31:57PM +0300, Nikolay Aleksandrov wrote:
>> On 18/04/18 15:07, Joachim Nilsson wrote:
>>> - First of all, is this patch useful to anyone
>> Obviously to us as it's based on our patch. :-)
>> We actually recently discussed what
Dear Shaohui,
I plead an indulgence if I have invaded your privacy by receiving this
mail from me without prior permission.With due respect,I contact you
purposely based on the similarities of names between you and my
deceased client who was an oil servicing contractor with shell
petroleum in West
adding selftests for bpf_xdp_adjust_tail helper. in this synthetic test
we are testing that 1) if data_end < data helper will return EINVAL
2) for normal use case packet's length would be reduced.
Signed-off-by: Nikita V. Shirokov
---
tools/include/uapi/linux/bpf.h | 10 +++-
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for virtio driver we need to adjust XDP_PASS handling by recalculating
length of the packet if it was p
Adding new bpf helper which would allow us to manipulate
xdp's data_end pointer, and allow us to reduce packet's size
indended use case: to generate ICMP messages from XDP context,
where such message would contain truncated original packet.
Signed-off-by: Nikita V. Shirokov
---
include/uapi/linu
In this patch series i'm add new bpf helper which allow to manupulate
xdp's data_end pointer. right now only "shrinking" (reduce packet's size
by moving pointer) is supported (and i see no use case for "growing").
Main use case for such helper is to be able to generate controll (ICMP)
messages from
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for mlx4 driver we will just calculate packet's length unconditionally
(the same way as it's already be
adding bpf's sample program which is using bpf_xdp_adjust_tail helper
by generating ICMPv4 "packet to big" message if ingress packet's size is
bigger then 600 bytes
Signed-off-by: Nikita V. Shirokov
---
samples/bpf/Makefile | 4 +
samples/bpf/xdp_adjust_tail_kern.c
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for bnxt driver we will just calculate packet's length unconditionally
Acked-by: Alexei Starovoitov
S
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for nfp driver we will just calculate packet's length unconditionally
Acked-by: Alexei Starovoitov
Ac
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for tun driver we need to adjust XDP_PASS handling by recalculating
length of the packet if it was pass
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for cavium's thunder driver we will just calculate packet's length
unconditionally
Acked-by: Alexei St
after introduction of bpf_xdp_adjust_tail helper packet length
could be changed not only if xdp->data pointer has been changed
but xdp->data_end as well. making bpf_prog_test_run aware of this
possibility
Signed-off-by: Nikita V. Shirokov
---
net/bpf/test_run.c | 3 ++-
1 file changed, 2 inserti
w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
well (only "decrease" of pointer's location is going to be supported).
changing of this pointer will change packet's size.
for generic XDP we need to reflect this packet's length change by
adjusting skb's tail pointer
Acked-b
On Wed, Apr 18, 2018 at 02:37:40PM +0200, Daniel Borkmann wrote:
> On 04/18/2018 06:29 AM, Nikita V. Shirokov wrote:
> > In this patch series i'm add new bpf helper which allow to manupulate
> > xdp's data_end pointer. right now only "shrinking" (reduce packet's size
> > by moving pointer) is suppo
On Wed, Apr 18, 2018 at 04:14:26PM +0300, Nikolay Aleksandrov wrote:
> We want to avoid sysfs in general, all of networking config and stats
> are moving to netlink. It is better controlled and structured for such
> changes, also provides nice interfaces for automatic type checks etc.
Aha, didn't
On Wed, Apr 18, 2018 at 02:48:18PM +0200, Jesper Dangaard Brouer wrote:
> On Tue, 17 Apr 2018 21:29:42 -0700
> "Nikita V. Shirokov" wrote:
>
> > w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
> > well (only "decrease" of pointer's location is going to be supported).
> >
While a faulty cable is used or HCA firmware error, HCA device will
be offline. When the driver is accessing this offline device, the
following call trace will pop out.
"
...
[] dump_stack+0x63/0x81
[] panic+0xcc/0x21b
[] mlx4_enter_error_state+0xba/0xf0 [mlx4_core]
[] mlx4_cmd_reset_flow+
On Tue, 17 Apr 2018 15:34:38 +0100
Quentin Monnet wrote:
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 350459c583de..3d329538498f 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -1276,6 +1276,50 @@ union bpf_attr {
> * Return
> *
On 04/18/2018 05:31 AM, Sowmini Varadhan wrote:
>
> I went through the patch set and the code looks fine- it extends existing
> infra for TCP/GSO to UDP.
>
> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT
> just be automatically determined in the stack from the pmtu? Wh
On (04/18/18 06:35), Eric Dumazet wrote:
>
> There is no change at all.
>
> This will only be used as a mechanism to send X packets of same size.
>
> So instead of X system calls , one system call.
>
> One traversal of some expensive part of the host stack.
>
> The content on the wire should b
Hi,
Because the timeout task gets the main spinlock and disable the current cpu's
irq,
there is no other task on the same cpu can run, and tasks on the other cpus can
not
enter the dm9000_timeout() again. So in the whole dm9000_timeout() routine,
db->timeout_cpu can not be changed by other tas
.
That also has few system calls, but observes per MTU stack traversal.
I pushed the branch to my github at
https://github.com/wdebruij/linux/tree/udpgso-20180418
and also the version I sent for RFC yesterday at
https://github.com/wdebruij/linux/tree/udpgso-rfc-v1
Hi Yonghong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Yonghong-Song/bpf-add-bpf_get_stack-helper/20180418-210810
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
On Wed, Apr 18, 2018 at 9:47 AM, Sowmini Varadhan
wrote:
> On (04/18/18 06:35), Eric Dumazet wrote:
>>
>> There is no change at all.
>>
>> This will only be used as a mechanism to send X packets of same size.
>>
>> So instead of X system calls , one system call.
>>
>> One traversal of some expensi
On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote:
> Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote:
> >Account for operational state when determining port linkup state,
> >as per Documentation/networking/operstates.txt.
>
> Could you please point me to the exact
> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT
> just be automatically determined in the stack from the pmtu? Whats
> the motivation for the socket option for this? also AIUI this can be
> either a per-socket or a per-packet option?
I decided to let the application expli
This modem is embedded on dlink dwr-960 router.
The oem configuration states:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1435 ProdID=d191 Rev=ff.ff
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=0
On Tue, Apr 17, 2018 at 04:35:18PM -0400, Vlad Yasevich wrote:
> On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote:
> > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote:
> >> Now that we have SCTP offload capabilities in the kernel, we can add
> >> them to virtio as well. Fir
2018-04-18 15:34 UTC+0200 ~ Jesper Dangaard Brouer
> On Tue, 17 Apr 2018 15:34:38 +0100
> Quentin Monnet wrote:
>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 350459c583de..3d329538498f 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>>
On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
> Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so
> remove the comments which suggest that they do.
>
> Signed-off-by: NeilBrown
> ---
> include/linux/rhashtable.h |3 ---
> lib/rhashtable.c |3 ---
>
On Wed, Apr 18, 2018 at 9:59 AM, Willem de Bruijn
wrote:
>> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT
>> just be automatically determined in the stack from the pmtu? Whats
>> the motivation for the socket option for this? also AIUI this can be
>> either a per-socket o
Rahul Lakkireddy writes:
> On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> Hi Rahul,
>> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporadically after days or even months
On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
> grow_decision and shink_decision no longer exist, so remove
> the remaining references to them.
>
> Signed-off-by: NeilBrown
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://g
The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc
fails (later patches change it to kvzalloc).
The problem with this is that if the vzalloc function is actually used,
virtio_net doesn't work (because it expects that the extra memory should
be accessible with DMA-API and m
On Wed, Apr 18, 2018 at 04:47:02PM +1000, NeilBrown wrote:
> rhashtable_walk_prev() returns the object returned by
> the previous rhashtable_walk_next(), providing it is still in the
> table (or was during this grace period).
> This works even if rhashtable_walk_stop() and rhashtable_talk_start()
>
Pawel Dembicki writes:
> This modem is embedded on dlink dwr-960 router.
> The oem configuration states:
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
> D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=1435 ProdID=d191 Rev=ff.ff
> S: Manufacturer=Androi
Wed, Apr 18, 2018 at 03:35:49PM CEST, gwil...@vyatta.att-mail.com wrote:
>On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote:
>> Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote:
>> >Account for operational state when determining port linkup state,
>> >as per Document
On 4/17/2018 5:30 PM, Yi-Hung Wei wrote:
s/to commit/from committing/
s/entry/entries/
Thanks, will fix that in both patches in v2.
I think this is a great idea but I suggest porting to the iproute2 package
so everyone can use it. Then git rid of the OVS specific prefixes.
Presuming of cours
On Wednesday, April 04/18/18, 2018 at 19:58:01 +0530, Eric W. Biederman wrote:
> Rahul Lakkireddy writes:
>
> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> >> Hi Rahul,
> >> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> >> > On production servers running variety
On 4/18/2018 6:51 AM, Willem de Bruijn wrote:
On Wed, Apr 18, 2018 at 9:47 AM, Sowmini Varadhan
wrote:
On (04/18/18 06:35), Eric Dumazet wrote:
There is no change at all.
This will only be used as a mechanism to send X packets of same size.
So instead of X system calls , one system call.
On
On Tue, Apr 17, 2018 at 04:19:15PM -0700, Jakub Kicinski wrote:
> On Tue, 17 Apr 2018 10:47:00 -0400, Andy Gospodarek wrote:
> > There is also a school of thought that the VF reps could be
> > pre-allocated on the SmartNIC so that any application processing that
> > traffic would sit idle when no t
Hi Martin,
first of all great work on the set! One issue that puzzled me
while digesting it further below.
On 04/17/2018 10:42 PM, Martin KaFai Lau wrote:
> This patch adds pretty print support to the basic arraymap.
> Support for other bpf maps can be added later.
>
> This patch adds new attrs
Hey,
This series deals with a bunch of performance improvements when sending out
uevents that have been extensively discussed here:
https://lkml.org/lkml/2018/4/10/592
- Only record uevent sockets from network namespaces owned by the
initial user namespace in the global uevent socket list.
Er
1 - 100 of 358 matches
Mail list logo
