RE: [PATCH net 1/2] net/mlx4_en: Change min MTU size to ETH_MIN_MTU

2018-12-04 Thread David Laight
From: Eric Dumazet > Sent: 04 December 2018 17:04 > On 12/04/2018 08:59 AM, David Laight wrote: > > From: Tariq Toukan > >> Sent: 02 December 2018 12:35 > >> From: Eran Ben Elisha > >> > >> NIC driver minimal MTU size shall be set to ETH_MIN_MTU,

RE: [PATCH net 1/2] net/mlx4_en: Change min MTU size to ETH_MIN_MTU

2018-12-04 Thread David Laight
From: Eric Dumazet > Sent: 04 December 2018 17:04 > > On 12/04/2018 08:59 AM, David Laight wrote: > > From: Tariq Toukan > >> Sent: 02 December 2018 12:35 > >> From: Eran Ben Elisha > >> > >> NIC driver minimal MTU size shall b

RE: [PATCH net 1/2] net/mlx4_en: Change min MTU size to ETH_MIN_MTU

2018-12-04 Thread David Laight
From: Tariq Toukan > Sent: 02 December 2018 12:35 > From: Eran Ben Elisha > > NIC driver minimal MTU size shall be set to ETH_MIN_MTU, as defined in > the RFC791 and in the network stack. Remove old mlx4_en only define for > it, which was set to wrong value. ... > > - /* MTU range: 46 -

RE: [PATCH net-next 2/2] net/sched: act_police: don't use spinlock in the data path

2018-11-16 Thread David Laight
From: Eric Dumazet > Sent: 16 November 2018 14:35 ... > I suggest to use a single cache line with a dedicated spinlock and these > three s64 > > spinlock_t tcfp_lock cacheline_aligned_in_smp; > s64 ... > s64 ... > s64

SCTP on RH 5.7

2018-11-05 Thread David Laight
Why do our customers insist on trying to use SCTP on RH 5.7 with its ancient 2.6.18 kernel. Not surprising they are getting issues! David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

RE: [PATCH net-next v2] net: core: change bool members of struct net_device to bitfield members

2018-10-10 Thread David Laight
From: Eric Dumazet > Sent: 09 October 2018 21:52 > > On 10/09/2018 01:24 PM, Heiner Kallweit wrote: > > > Reordering the struct members to fill the holes could be a little tricky > > and could have side effects because it may make a performance difference > > whether certain members are in one

RE: [PATCH net-next] net: core: change bool members of struct net_device to bitfield members

2018-10-09 Thread David Laight
From: Heiner Kallweit > Sent: 08 October 2018 21:01 > > bool is good as parameter type or function return type, but if used > for struct members it consumes more memory than needed. Actually it can generate extra code when used as a parameter or return type - but DM doesn't seem to worry about

RE: [RFC PATCH] skb: Define NET_IP_ALIGN based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

2018-10-05 Thread David Laight
From: Ben Hutchings > Sent: 04 October 2018 18:37 > > NET_IP_ALIGN is supposed to be defined as 0 if DMA writes to an > unaligned buffer would be more expensive than CPU access to unaligned > header fields, and otherwise defined as 2. > > Currently only ppc64 and x86 configurations define it to

RE: [PATCH v2 1/5] netlink: remove NLA_NESTED_COMPAT

2018-09-20 Thread David Laight
From: Johannes Berg > Sent: 19 September 2018 20:49 > This isn't used anywhere, so we might as well get rid of it. > > Reviewed-by: David Ahern > Signed-off-by: Johannes Berg > --- > include/net/netlink.h | 2 -- > lib/nlattr.c | 11 --- > 2 files changed, 13 deletions(-) >

RE: [PATCH 1/2] staging: rtl8192e: Fix compiler warning about strncpy

2018-08-21 Thread David Laight
From: Larry Finger > Sent: 20 August 2018 18:51 > When strncpy() is called with source and destination strings the same > length, gcc 8 warns that there may be an unterminated string. Using > strlcpy() rather than strncpy() forces a null at the end and quiets the > warning. > > Signed-off-by:

RE: [iproute PATCH 4/4] lib: Enable colored output only for TTYs

2018-08-15 Thread David Laight
From: Stephen Hemminger > Sent: 15 August 2018 16:04 ... > > This also disables color sequence when the output is piped to a pager > > such as less which with the -R argument can handle it just fine. > > > > ie., the user needs to remove the color arg when that output is not wanted. > > If you

RE: [PATCH v2 0/2] net/sctp: Avoid allocating high order memory with kmalloc()

2018-08-06 Thread David Laight
From: Michael Tuexen > Sent: 03 August 2018 21:57 ... > >> Given how useless SCTP streams are, does anything actually use > >> more than about 4? > > > > Maybe Michael can help us with that. I'm also curious now. > In the context of SIGTRAN I have seen 17 streams... Ok, I've seen 17 there as

RE: [PATCH v2 0/2] net/sctp: Avoid allocating high order memory with kmalloc()

2018-08-03 Thread David Laight
From: Konstantin Khorenko > Sent: 03 August 2018 17:21 > > Each SCTP association can have up to 65535 input and output streams. > For each stream type an array of sctp_stream_in or sctp_stream_out > structures is allocated using kmalloc_array() function. This function > allocates physically

RE: [PATCH v2 1/2] net/sctp: Make wrappers for accessing in/out streams

2018-08-03 Thread David Laight
From: Konstantin Khorenko > Sent: 03 August 2018 17:21 ... > --- a/net/sctp/stream.c > +++ b/net/sctp/stream.c > @@ -37,6 +37,18 @@ > #include > #include > > +struct sctp_stream_out *sctp_stream_out(const struct sctp_stream *stream, > + __u16 sid) > +{ > +

RE: [PATCH net-next] sctp: add support for SCTP_REUSE_PORT sockopt

2018-05-22 Thread David Laight
... > > >> the reason this was added is to have a specified way to allow a system to > > >> behave like a client and server making use of the INIT collision. > > >> > > >> For 1-to-many style sockets you can do this by creating a socket, > > >> binding it, > > >> calling listen on it and trying

RE: [PATCH v2] net: dsa: drop some VLAs in switch.c

2018-05-08 Thread David Laight
From: Salvatore Mesoraca > Sent: 07 May 2018 20:03 ... > This optimization will save us an allocation when number of ports is > less than 32 or 64 (depending on arch). > IMHO it's useful, if you consider that, right now, DSA works only with > 12-ports switches. Why not just error out if the

RE: [PATCH 000/109] remove in-kernel calls to syscalls

2018-03-29 Thread David Laight
From: Dominik Brodowski > Sent: 29 March 2018 15:42 > On Thu, Mar 29, 2018 at 07:20:27AM -0700, Matthew Wilcox wrote: > > On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote: > > > At least on 64-bit x86, it will likely be a hard requirement from v4.17 > > > onwards to not call

RE: RFC on writel and writel_relaxed

2018-03-28 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 28 March 2018 16:13 ... > > I've always wondered exactly what the twi;isync were for - always seemed > > very heavy handed for most mmio reads. > > Particularly if you are doing mmio reads from a data fifo. > > If you do that you should use the "s" version of

RE: RFC on writel and writel_relaxed

2018-03-28 Thread David Laight
From: Benjamin Herrenschmidt > Sent: 28 March 2018 10:56 ... > For example, let's say I have a device with a reset bit and the spec > says the reset bit needs to be set for at least 10us. > > This is wrong: > > writel(1, RESET_REG); > usleep(10); > writel(0, RESET_REG); > >

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

2018-03-22 Thread David Laight
From: Kees Cook > Sent: 22 March 2018 15:01 ... > > /* Glory to Martin Uecker */ > > #define __is_constant(a) \ > > (sizeof(int) == sizeof(*(1 ? ((void*)((a) * 0l)) : (int*)1))) ... > So, this time it's not a catastrophic failure with gcc 4.4.

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-22 Thread David Laight
From: David Laight > Sent: 22 March 2018 10:36 ... > Any code would need to be in memcpy_fromio(), not in every driver that > might benefit. > Then fallback code can be used if the registers aren't available. > > > (b) we can't guarantee that %ymm register write will s

RE: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write

2018-03-22 Thread David Laight
From: Linus Torvalds > Sent: 22 March 2018 01:27 > On Tue, Mar 20, 2018 at 7:42 AM, Alexander Duyck > wrote: > > > > Instead of framing this as an enhanced version of the read/write ops > > why not look at replacing or extending something like the > > memcpy_fromio or

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-22 Thread David Laight
From: Sent: 21 March 2018 18:16 > To: Ingo Molnar ... > All this to do a 32-byte PIO access, with absolutely zero data right > now on what the win is? > > Yes, yes, I can find an Intel white-paper that talks about setting WC > and then using xmm and ymm instructions to write a single 64-byte >

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-20 Thread David Laight
From: Andy Lutomirski > Sent: 20 March 2018 14:57 ... > I'd rather see us finally finish the work that Rik started to rework > this differently. I'd like kernel_fpu_begin() to look like: > > if (test_thread_flag(TIF_NEED_FPU_RESTORE)) { > return; // we're already okay. maybe we need to check

RE: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write

2018-03-20 Thread David Laight
From: Rahul Lakkireddy > Sent: 20 March 2018 13:32 ... > On High Availability Server, the logs of the failing system must be > collected as quickly as possible. So, we're concerned with the amount > of time taken to collect our large on-chip memory. We see improvement > in doing 256-bit reads at

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-20 Thread David Laight
From: Ingo Molnar > Sent: 20 March 2018 10:54 ... > Note that a generic version might still be worth trying out, if and only if > it's > safe to access those vector registers directly: modern x86 CPUs will do their > non-constant memcpy()s via the common memcpy_erms() function - which could in >

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-20 Thread David Laight
From: Thomas Gleixner > Sent: 20 March 2018 09:41 > On Tue, 20 Mar 2018, Ingo Molnar wrote: > > * Thomas Gleixner wrote: ... > > > And if we go down that road then we want a AVX based memcpy() > > > implementation which is runtime conditional on the feature bit(s) and > > >

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-19 Thread David Laight
From: Thomas Gleixner > Sent: 19 March 2018 15:37 ... > > If system call entry reset the AVX registers then any FP save/restore > > would be faster because the AVX registers wouldn't need to be saved > > (and the cpu won't save them). > > I believe the instruction to reset the AVX registers is

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-19 Thread David Laight
From: Thomas Gleixner > Sent: 19 March 2018 15:05 > > On Mon, 19 Mar 2018, David Laight wrote: > > From: Rahul Lakkireddy > > In principle it ought to be possible to get access to one or two > > (eg) AVX registers by saving them to stack and telling the fpu > >

RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access

2018-03-19 Thread David Laight
From: Rahul Lakkireddy > Sent: 19 March 2018 14:21 > > This series of patches add support for 256-bit IO read and write. > The APIs are readqq and writeqq (quad quadword - 4 x 64), that read > and write 256-bits at a time from IO, respectively. Why not use the AVX2 registers to get 512bit

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

2018-03-19 Thread David Laight
From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus Torvalds > Sent: 18 March 2018 23:36 ... > > Yeah, and since we're in the situation that *new* gcc versions work > for us anyway, and we only have issues with older gcc's (that sadly > people still use), even if there was a

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

2018-03-16 Thread David Laight
From: Linus Torvalds > Sent: 16 March 2018 17:29 > On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > > > If you want to catch stack frames which have unbounded size, > > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > > adjusted as

RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

2018-03-14 Thread David Laight
From: Kees Cook > Sent: 13 March 2018 22:15 ... > I'll send a "const_max()" which will refuse to work on > non-constant-values (so it doesn't get accidentally used on variables > that could be exposed to double-evaluation), and will work for stack > array declarations (to avoid the

RE: [PATCH] net: dsa: drop some VLAs in switch.c

2018-03-14 Thread David Laight
From: Salvatore Mesoraca > Sent: 13 March 2018 22:01 > 2018-03-13 20:58 GMT+01:00 Vivien Didelot > : > > Hi Salvatore, > > Hi Vivien, > > > Salvatore Mesoraca writes: > > > >> dsa_switch's num_ports is currently fixed to

RE: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

2018-03-13 Thread David Laight
The amount of replicated defined could also be reduced by passing > or < to a min_max() macro. So you start off with something like: #define min(x, y) __min_max(x, <, y) #define max(x, y) __min_max(x, >, y) then have: #define __min_max(x, cond, y) ((x) cond (y) ? (x) : (y)) in all its associated

RE: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

2018-03-13 Thread David Laight
From: Daniel Micay > Sent: 10 March 2018 23:45 > > > Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > > not really going to show a lot of variation. This array will always have the > > same size on the stack. > > The issue is that unlike in C++, a `static const`

RE: [PATCH net 3/4] net: dsa: microchip: Utilize strncpy() for ethtool::get_strings

2018-03-02 Thread David Laight
From: Florian Fainelli > > Do not use memcpy() which is not safe, but instead use strncpy() which > will make sure that the string is NUL terminated (in the Linux > implementation) if the string is smaller than the length specified. This > fixes KASAN out of bounds warnings while fetching port

RE: [PATCH RFC 1/2] virtio: introduce packed ring defines

2018-02-27 Thread David Laight
From: Tiwei Bie > Sent: 23 February 2018 11:18 ... > +struct vring_packed_desc_event { > + /* Descriptor Event Offset */ > + __virtio16 desc_event_off : 15, > + /* Descriptor Event Wrap Counter */ > +desc_event_wrap : 1; > + /* Descriptor Event Flags */ > +

RE: [PATCH v5 07/14] net: pch_gbe: Fix handling of TX padding

2018-02-19 Thread David Laight
From: Paul Burton > Sent: 17 February 2018 20:11 > > The ethernet controller found in the Intel EG20T Platform Controller > Hub requires that we place 2 bytes of padding between the ethernet > header & the packet payload. Our pch_gbe driver handles this by copying > packets to be transmitted to a

RE: [net-next v2 1/1] tipc: avoid unnecessary copying of bundled messages

2018-02-19 Thread David Laight
From: Jon Maloy Date: Thu, 15 Feb 2018 14:14:37 +0100 > A received sk buffer may contain dozens of smaller 'bundled' messages > which after extraction go each in their own direction. > > Unfortunately, when we extract those messages using skb_clone() each > of the

RE: [PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

2018-02-19 Thread David Laight
From: Colin King > Sent: 16 February 2018 16:55 > > From: Colin Ian King > > The shifting of timehi by 16 bits to the left will be promoted to > a 32 bit signed int and then sign-extended to an u64. If the top bit > of timehi is set then all then all the upper bits of

RE: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

2018-02-06 Thread David Laight
From: Eric Dumazet > Sent: 06 February 2018 14:20 ... > Please give exact details. > Sending 64, 128, 256 or 512 bytes at a time on TCP_STREAM makes little sense. > We are not optimizing stack for pathological cases, sorry. There are plenty of workloads which are not bulk data and where multiple

RE: [PATCH] net: cxgb4: avoid memcpy beyond end of source buffer

2018-02-02 Thread David Laight
From: Arnd Bergmann > Sent: 02 February 2018 15:19 > > Building with link-time-optimizations revealed that the cxgb4 driver does > a fixed-size memcpy() from a variable-length constant string into the > network interface name: ... > I can see two equally workable solutions: either we use a

RE: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit

2018-02-01 Thread David Laight
> > The question you need to ask is 'can it overflow 32bit maths', otherwise > > you are potentially making the system do extra work for no reason. > > > > Yeah, I get your point and it seems that in this particular case there > is no risk of a 32bit overflow, but in general and IMHO as the code

RE: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting

2018-01-12 Thread David Laight
From: Christopher Lameter > Sent: 10 January 2018 18:28 > On Tue, 9 Jan 2018, Kees Cook wrote: > > > +struct kmem_cache *kmem_cache_create_usercopy(const char *name, > > + size_t size, size_t align, slab_flags_t flags, > > + size_t useroffset, size_t usersize,

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

2018-01-08 Thread David Laight
From: Alan Cox > Sent: 08 January 2018 12:13 ... > > Try over 35% slowdown > > Given that AWS instance runs known code (user and kernel) why do we > > need to worry about any of these sideband attacks? > > You may not need to. Amazon themselves obviously need to worry that no > other VM

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

2018-01-08 Thread David Laight
From: Linus Torvalds > Sent: 07 January 2018 19:47 ... > Also, people definitely *are* noticing the performance issues with the > current set of patches, and they are causing real problems. Go search > for reports of Amazon AWS slowdowns. Try over 35% slowdown Given that AWS instance runs

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

2017-12-08 Thread David Laight
From: Xin Long ... > Hi, David, Sorry, I'm not sure we're worrying about the cpu cost or > codes style now ? > > For cpu cost, I think 0x848(%r13) operation must be better than the > generated code of if-else. Nope - the call xxx(%ryyy) is likely to be a data cache miss and a complete cpu

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

2017-12-08 Thread David Laight
From: Xin Long > Sent: 08 December 2017 16:18 > ... > >> Alternatively you could preform the dereference in two steps (i.e. declare > >> an si > >> pointer on the stack and set it equal to asoc->stream.si, then deref > >> si->make_datafrag at call time. That will at least give the compiler an >

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

2017-12-08 Thread David Laight
From: Marcelo Ricardo Leitner > Sent: 08 December 2017 16:00 ... > > Is it worth replacing the si struct with an index/enum value, and indexing > > an > > array of method pointer structs? That would save you at least one > > dereference. > > Hmmm, maybe, yes. It would be like >

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

2017-12-08 Thread David Laight
From: 'Marcelo Ricardo Leitner' > Sent: 08 December 2017 15:16 > On Fri, Dec 08, 2017 at 03:01:31PM +, David Laight wrote: > > From: Marcelo Ricardo Leitner > > > Sent: 08 December 2017 14:57 > > > > > > On Fri, Dec 08, 2017 at 02:06:04PM +, Dav

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

2017-12-08 Thread David Laight
From: Marcelo Ricardo Leitner > Sent: 08 December 2017 14:57 > > On Fri, Dec 08, 2017 at 02:06:04PM +0000, David Laight wrote: > > From: Xin Long > > > Sent: 08 December 2017 13:04 > > ... > > > @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_us

RE: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for sctp_stream_interleave

2017-12-08 Thread David Laight
From: Xin Long > Sent: 08 December 2017 13:04 ... > @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct > sctp_association *asoc, > frag |= SCTP_DATA_SACK_IMM; > } > > - chunk = sctp_make_datafrag_empty(asoc, sinfo, len,

RE: [PATCH V11 3/5] printk: hash addresses printed with %p

2017-12-06 Thread David Laight
From: David Miller > Sent: 05 December 2017 20:31 ... > > Would it make sense to keep the 3 lowest bits of the address? > > > > Currently printed pointers no longer have any correlation with the actual > > alignment in memory of the object, which is a typical cause of a class of > > bugs. > >

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

2017-11-30 Thread David Laight
From: Kees Cook > Sent: 29 November 2017 22:28 > On Wed, Nov 29, 2017 at 2:07 AM, David Laight <david.lai...@aculab.com> wrote: > > From: Linus Torvalds > >> Sent: 29 November 2017 02:29 > >> > >> On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding <

RE: [PATCH V11 0/5] hash addresses printed with %p

2017-11-30 Thread David Laight
From: Andrew Morton > Sent: 29 November 2017 23:21 > > > > The added advantage of hashing %p is that security is now opt-out, if > > you _really_ want the address you have to work a little harder and use > > %px. You need a system-wide opt-out that prints the actual values. Otherwise developers

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

2017-11-29 Thread David Laight
From: Linus Torvalds > Sent: 29 November 2017 02:29 > > On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding wrote: > > > >Let's add specifier %px as a > > clear, opt-in, way to print a pointer and maintain some level of > > isolation from all the other hex integer output within

RE: [PATCH net 3/5] sctp: only allow the asoc reset when the asoc outq is empty

2017-11-27 Thread David Laight
From: Xin Long > Sent: 25 November 2017 13:06 > > As it says in rfc6525#section5.1.4, before sending the request, > >C2: The sender has either no outstanding TSNs or considers all > outstanding TSNs abandoned. > > Prior to this patch, it tried to consider all outstanding TSNs

RE: [PATCH] net: bridge: add max_fdb_count

2017-11-21 Thread David Laight
From: Sarah Newman > Sent: 15 November 2017 19:27 > Current memory and CPU usage for managing bridge fdb entries is unbounded. > Add a parameter max_fdb_count, controlled from sysfs, which places an upper > limit on the number of entries. Defaults to 1024. > > When max_fdb_count is met or

RE: [net-next 1/1] tipc: enforce valid ratio between skb truesize and contents

2017-11-21 Thread David Laight
From: Jon Maloy > Sent: 15 November 2017 20:24 > The socket level flow control is based on the assumption that incoming > buffers meet the condition (skb->truesize / roundup(skb->len) <= 4), > where the latter value is rounded off upwards to the nearest 1k number. > This does empirically hold true

RE: [PATCH 0/9] use network namespace for iSCSI control interfaces

2017-11-21 Thread David Laight
From: Chris Leech > Sent: 15 November 2017 00:25 > To: David Laight > Cc: netdev@vger.kernel.org; contain...@lists.linux-foundation.org > Subject: Re: [PATCH 0/9] use network namespace for iSCSI control interfaces > > On Wed, Nov 08, 2017 at 10:31:04AM +, David Laight wrot

RE: [PATCH] net: mvneta: fix handling of the Tx descriptor counter

2017-11-20 Thread David Laight
From: Simon Guinot > Sent: 13 November 2017 15:36 > To: David Miller > Cc: thomas.petazz...@free-electrons.com; netdev@vger.kernel.org; m...@gmx.de; > andreas.tob...@cloudguard.ch; gregory.clem...@free-electrons.com; > antoine.ten...@free-electrons.com; > m...@semihalf.com; sta...@vger.kernel.org

RE: [PATCH net-next] net: thunderbolt: Clear finished Tx frame bus address in tbnet_tx_callback()

2017-11-20 Thread David Laight
From: Mika Westerberg > Sent: 13 November 2017 10:22 > To: David Miller > Cc: michael.ja...@intel.com; yehezkel.ber...@intel.com; netdev@vger.kernel.org > Subject: Re: [PATCH net-next] net: thunderbolt: Clear finished Tx frame bus > address in > tbnet_tx_callback() > > On Sat, Nov 11, 2017 at

RE: [PATCH 3/7] net: core: eliminate dev_alloc_name{,_ns} code duplication

2017-11-20 Thread David Laight
From: Rasmus Villemoes > Sent: 12 November 2017 23:15 > dev_alloc_name contained a BUG_ON(), which I moved to dev_alloc_name_ns; > the only other caller of that already has the same BUG_ON. > > Signed-off-by: Rasmus Villemoes > --- > net/core/dev.c | 12 ++-- >

RE: [PATCH net-next v2 1/3] net: bgmac: Pad packets to a minimum size

2017-11-10 Thread David Laight
From: Florian Fainelli > Sent: 09 November 2017 22:35 > > In preparation for enabling Broadcom tags with b53, pad packets to a > minimum size of 64 bytes (sans FCS) in order for the Broadcom switch to > accept ingressing frames. Without this, we would typically be able to > DHCP, but not resolve

RE: [PATCH x86 v2] uprobe: emulate push insns for uprobe on x86

2017-11-09 Thread David Laight
From: Yonghong Song > Sent: 09 November 2017 00:55 > > Uprobe is a tracing mechanism for userspace programs. > Typical uprobe will incur overhead of two traps. > First trap is caused by replaced trap insn, and > the second trap is to execute the original displaced > insn in user space. > > To

RE: [PATCH] net: mvneta: fix handling of the Tx descriptor counter

2017-11-08 Thread David Laight
From: Simon Guinot > Sent: 08 November 2017 16:59 > > The mvneta controller provides a 8-bit register to update the pending > Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be > added at once. In the current code the mvneta_txq_pend_desc_add function > assumes the caller takes

RE: mlx5 broken affinity

2017-11-08 Thread David Laight
From: Sagi Grimberg > Sent: 08 November 2017 07:28 ... > > Why would you give the user a knob to destroy what you carefully optimized? > > Well, looks like someone relies on this knob, the question is if he is > doing something better for his workload. I don't know, its really up to > the user to

RE: [PATCH 0/9] use network namespace for iSCSI control interfaces

2017-11-08 Thread David Laight
From: Chris Leech > Sent: 07 November 2017 22:45 > > I've posted these changes to allow iSCSI management within a container > using a network namespace to the SCSI and Open-iSCSI lists, but seeing > as it's not really SCSI/block related I'm casting a wider net looking > for reviews. I didn't

RE: [PATCH v4] scripts: add leaking_addresses.pl

2017-11-07 Thread David Laight
From: Tobin C. Harding > Sent: 07 November 2017 10:32 > > Currently we are leaking addresses from the kernel to user space. This > script is an attempt to find some of those leakages. Script parses > `dmesg` output and /proc and /sys files for hex strings that look like > kernel addresses. ...

RE: [PATCH] [net-next,v2] ibmvnic: Feature implementation of Vital Product Data (VPD) for the ibmvnic driver

2017-11-06 Thread David Laight
From: David Miller > Sent: 04 November 2017 13:21 > From: Desnes Augusto Nunes do Rosario > Date: Wed, 1 Nov 2017 19:03:32 -0200 > > > + substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len); > > + if (!substr) { > > + dev_info(dev, "No FW level

RE: [PATCH net-next v2 1/3] enic: reset fetch index

2017-11-03 Thread David Laight
From: Parvi Kaustubhi > Sent: 01 November 2017 15:45 > Since we are allowing rx ring size modification, reset fetch index > everytime. Otherwise it could have a stale value that can lead to a null > pointer dereference. > > Signed-off-by: Govindarajulu Varadarajan >

RE: [PATCH net-next 1/1] forcedeth: replace pci_alloc_consistent with dma_alloc_coherent

2017-10-30 Thread David Laight
From: Zhu Yanjun > Sent: 28 October 2017 13:26 > The functions pci_alloc_consistent is obsolete. So it is replaced > with dma_alloc_coherent ... > + dma_free_coherent(>pci_dev->dev, > + sizeof(struct ring_desc) * > +

RE: [PATCH net 4/4] sctp: fix some type cast warnings introduced since very beginning

2017-10-30 Thread David Laight
From: Xin Long > Sent: 28 October 2017 12:44 > These warnings were found by running 'make C=2 M=net/sctp/'. > They are there since very beginning. ... > - param.crr_id = i; > + param.crr_id = htonl(i); ... Isn't this a bug fix, not just removing a warning?? David

RE: [PATCH net-next 1/3] ibmvnic: Enable scatter-gather support

2017-10-27 Thread David Laight
From: Thomas Falcon > Sent: 26 October 2017 18:52 ... > >>memset(dst, 0, adapter->req_mtu); > > Seems unnecessary. > > I removed that bit, and so far you seem to be right :) . I'd check that short frames are padded with zeros. David

RE: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

2017-10-26 Thread David Laight
From: Willem de Bruijn > Sent: 25 October 2017 19:50 ... > From skb->dev and netdev_priv, the tun device has flags 0x1002 == > IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for > IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely happened > in tun_build_skb from

RE: Get rid of RCU callbacks in TC filters?

2017-10-23 Thread David Laight
From: Cong Wang > Sent: 20 October 2017 21:52 > To: Paul E. McKenney > Cc: Jamal Hadi Salim; Chris Mi; Linux Kernel Network Developers; Daniel > Borkmann; Eric Dumazet; David > Miller; Jiri Pirko > Subject: Re: Get rid of RCU callbacks in TC filters? > > On Fri, Oct 20, 2017 at 1:31 PM, Cong

RE: [PATCH net-next 6/8] tools: bpftool: print all relevant byte opcodes for "load double word"

2017-10-20 Thread David Laight
From: Jakub Kicinski > Sent: 19 October 2017 23:46 > The eBPF instruction permitting to load double words (8 bytes) into a > register need 8-byte long "immediate" field, and thus occupy twice the > space of other instructions. bpftool was aware of this and would > increment the instruction counter

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods

2017-10-20 Thread David Laight
From: Egil Hjelmeland > Sent: 19 October 2017 17:53 ... > >> IMHO it is best to define a struct for the 'ctx and then do: > >> ..., void *v_ctx) > >> { > >> foo_ctx *ctx = v_ctx; > >> int port = ctx->port; > >> > >> That stops anyone having to double-check that the *(int *) > >> is

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods

2017-10-19 Thread David Laight
From: Andrew Lunn > Sent: 19 October 2017 15:15 > > > +/* Clear learned (non-static) entry on given port */ > > > +static void alr_loop_cb_del_port_learned(struct lan9303 *chip, u32 dat0, > > > + u32 dat1, int portmap, void *ctx) > > > +{ > > > + int *port = ctx; >

RE: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

2017-10-18 Thread David Laight
From: Ard Biesheuvel > Sent: 18 October 2017 16:45 > Even though calling dql_completed() with a count that exceeds the > queued count is a serious error, it still does not justify bringing > down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() > instead. > > Signed-off-by: Ard

RE: [PATCH net-next 1/3] ibmvnic: Enable scatter-gather support

2017-10-18 Thread David Laight
From: Thomas Falcon > Sent: 17 October 2017 18:37 > This patch enables scatter gather support. Since there is no > HW/FW scatter-gather support at this time, the driver needs to > loop through each fragment and copy it to a contiguous, pre-mapped > buffer entry. ... > offset = index *

RE: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat

2017-10-17 Thread David Laight
From: Daniel Borkmann > Sent: 17 October 2017 15:56 > > The set fixes a splat in devmap percpu allocation when we alloc > the flush bitmap. Patch 1 is a prerequisite for the fix in patch 2, > patch 1 is rather small, so if this could be routed via -net, for > example, with Tejun's Ack that would

RE: [PATCH net-next v3 0/5] net: dsa: remove .set_addr

2017-10-16 Thread David Laight
From: Andrew Lunn > Sent: 16 October 2017 17:10 ... > So, received Pause frames never leave the MAC. They don't get bridged, > nor do they get passed up for host processing. They are purely point > to point between two MAC peers. The destination is unambiguous. It is > simple the other MAC peer.

RE: [net-next 6/9] e1000e: fix buffer overrun while the I219 is processing DMA transactions

2017-10-16 Thread David Laight
From: Neftin, Sasha > Sent: 16 October 2017 11:40 > On 10/11/2017 12:07, David Laight wrote: > > From: Jeff Kirsher > >> Sent: 10 October 2017 18:22 > >> Intel 100/200 Series Chipset platforms reduced the round-trip > >> latency for the LAN Contro

RE: [PATCH net-next 00/10] korina cleanups/optimizations

2017-10-16 Thread David Laight
From: Roman Yeryomin > Sent: 15 October 2017 17:22 > TX optimizations have led to ~15% performance increase (35->40Mbps) > in local tx usecase (tested with iperf v3.2). Indicate which patches give the improvement. IIRC some just changed the source without changing what the code really did. (Not a

RE: [next-queue PATCH v7 4/6] net/sched: Introduce Credit Based Shaper (CBS) qdisc

2017-10-16 Thread David Laight
From: Ivan Khoronzhuk > Sent: 13 October 2017 20:59 > On Thu, Oct 12, 2017 at 05:40:03PM -0700, Vinicius Costa Gomes wrote: > > This queueing discipline implements the shaper algorithm defined by > > the 802.1Q-2014 Section 8.6.8.2 and detailed in Annex L. > > > > It's primary usage is to apply

RE: [PATCH net-next v3 3/5] net: dsa: mv88e6060: setup random mac address

2017-10-16 Thread David Laight
From: Vivien Didelot > Sent: 13 October 2017 19:18 > As for mv88e6xxx, setup the switch from within the mv88e6060 driver with > a random MAC address, and remove the .set_addr implementation. > > Signed-off-by: Vivien Didelot > --- >

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

2017-10-16 Thread David Laight
From: woojung@microchip.com > Sent: 13 October 2017 18:59 > > >> > + REG_WRITE(REG_GLOBAL, GLOBAL_MAC_01, (addr[0] << 9) | > > >> addr[1]); > > >> > > >> Is that supposed to be 9 ? > > > > > > Looks like it. > > > Check > >

RE: Kernel Performance Tuning for High Volume SCTP traffic

2017-10-13 Thread David Laight
From: Traiano Welcome > Sent: 13 October 2017 17:04 > On Fri, Oct 13, 2017 at 11:56 PM, David Laight <david.lai...@aculab.com> > wrote: > > From: Traiano Welcome > > > > (copied to netdev) > >> Sent: 13 October 2017 07:16 > >> To: linux-s...@vger

RE: [PATCH net-next 5/5] net: dsa: split dsa_port's netdev member

2017-10-13 Thread David Laight
From: Vivien Didelot > Sent: 13 October 2017 16:29 > Vivien Didelot writes: > > >>> How about using: > >>> > >>> union { > >>> struct net_device *master; > >>> struct net_device *slave; > >>> } netdev; > >> ... > >> > >> You can remove

RE: Kernel Performance Tuning for High Volume SCTP traffic

2017-10-13 Thread David Laight
From: Traiano Welcome (copied to netdev) > Sent: 13 October 2017 07:16 > To: linux-s...@vger.kernel.org > Subject: Kernel Performance Tuning for High Volume SCTP traffic > > Hi List > > I'm running a linux server processing high volumes of SCTP traffic and > am seeing large numbers of packet

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

2017-10-13 Thread David Laight
From: Vivien Didelot > Sent: 13 October 2017 02:41 > As for mv88e6xxx, setup the switch from within the mv88e6060 driver with > a random MAC address, and remove the .set_addr implementation. > > Signed-off-by: Vivien Didelot > --- >

RE: [PATCH net-next 5/5] net: dsa: split dsa_port's netdev member

2017-10-13 Thread David Laight
From: Florian Fainelli > Sent: 13 October 2017 00:05 ... > How about using: > > union { > struct net_device *master; > struct net_device *slave; > } netdev; ... You can remove the 'netdev' all the compilers support unnamed unions. David

RE: [PATCH 3/4] net: qcom/emac: enforce DMA address restrictions

2017-10-12 Thread David Laight
From: Timur Tabi > Sent: 12 October 2017 15:13 > On 10/12/17 4:30 AM, David Laight wrote: > > Isn't the memory allocated by a single kzalloc() call? > > dma_alloc_coherenent, actually. > > > IIRC that guarantees it doesn't cross a power or 2 boundary less than > &g

RE: [PATCH 3/4] net: qcom/emac: enforce DMA address restrictions

2017-10-12 Thread David Laight
From: Timur Tabi > Sent: 11 October 2017 20:52 > The EMAC has a restriction that the upper 32 bits of the base addresses > for the RFD and RRD rings must be the same. The ensure that restriction, > we allocate twice the space for the RRD and locate it at an appropriate > address. > > We also

RE: [PATCH] rtl8xxxu: mark expected switch fall-throughs

2017-10-11 Thread David Laight
From: Joe Perches > Sent: 11 October 2017 11:21 > On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > > where we are expecting to fall through. > > perhaps use Arnaldo's idea: > >

RE: [PATCH v2] xdp: Sample xdp program implementing ip forward

2017-10-11 Thread David Laight
From: Jesper Dangaard Brouer > Sent: 10 October 2017 20:06 ... > > + int src_ip = 0, dest_ip = 0; ... > > + key4.b8[4] = dest_ip % 0x100; > > + key4.b8[5] = (dest_ip >> 8) % 0x100; > > + key4.b8[6] = (dest_ip >> 16) % 0x100; > > +

RE: [net-next 6/9] e1000e: fix buffer overrun while the I219 is processing DMA transactions

2017-10-11 Thread David Laight
From: Jeff Kirsher > Sent: 10 October 2017 18:22 > Intel 100/200 Series Chipset platforms reduced the round-trip > latency for the LAN Controller DMA accesses, causing in some high > performance cases a buffer overrun while the I219 LAN Connected > Device is processing the DMA transactions. I219LM

RE: [patch net-next 2/4] net: sched: introduce per-egress action device callbacks

2017-10-10 Thread David Laight
From: Jiri Pirko > Sent: 10 October 2017 15:32 > To: David Laight > Cc: netdev@vger.kernel.org; da...@davemloft.net; j...@mojatatu.com; > xiyou.wangc...@gmail.com; > sae...@mellanox.com; mat...@mellanox.com; leo...@mellanox.com; > ml...@mellanox.com > Subject: Re: [patch net

  1   2   3   4   5   6   7   >