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

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 2/3] x86/io: implement 256-bit IO read and write

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

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 0/3] kernel: add support for 256-bit IO access

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 0/3] kernel: add support for 256-bit IO access

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 2/3] x86/io: implement 256-bit IO read and write

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: [PATCH v5 0/2] Remove false-positive VLAs when using max()

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: [PATCH RFC 1/2] virtio: introduce packed ring defines

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 net 3/4] net: dsa: microchip: Utilize strncpy() for ethtool::get_strings

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: [RFC PATCH] skb: Define NET_IP_ALIGN based on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

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

SCTP on RH 5.7

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 2/2] net/sched: act_police: don't use spinlock in the data path

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

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

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: [PATCH net-next v2] net: core: change bool members of struct net_device to bitfield members

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 v2 1/5] netlink: remove NLA_NESTED_COMPAT

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 net 1/2] net/mlx4_en: Change min MTU size to ETH_MIN_MTU

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

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

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 -

<    2   3   4   5   6   7