similar to: [PATCH net-next V4 0/6] switch to use tx skb array in tun

On Wed, Jul 06, 2016 at 01:45:58PM -0400, Craig Gallek wrote: > On Thu, Jun 30, 2016 at 2:45 AM, Jason Wang <jasowang at redhat.com> wrote: > > Hi all: > > > > This series tries to switch to use skb array in tun. This is used to > > eliminate the spinlock contention between producer and consumer. The > > conversion was straightforward: just introdce a tx skb

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

CentOS Errata and Enhancement Advisory 2012:0739 Upstream details at : https://rhn.redhat.com/errata/RHEA-2012-0739.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 4535fe7fca08e503ad67afe4ba8371c3def9069118ac9528647cf264012f6f43 kmod-mlx4_en-2.0.32.269-1.el6_2.i686.rpm x86_64:

The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next for you to fetch changes up to 2ae76693b8bcabf370b981cd00c36cd41d33fabc: vhost: replace rcu with mutex (2014-06-02 23:47:59

The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next for you to fetch changes up to 2ae76693b8bcabf370b981cd00c36cd41d33fabc: vhost: replace rcu with mutex (2014-06-02 23:47:59

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Hi have what might be some elementary questions. Really, what I"d love would be for someone who has had good success to publish his/her configuration files and, maybe, the output from ifconfig. At this point, when I see the not-so-good performance I"m getting, I don't realistically know if I'm in the right ballfield. It seems to me, that with so many mellanox cards out

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: b5fe11663b48ca267829b34a65b4133e4e34c993 commit: 1f4098ea671b092af3806789d89e278e1f08e222 [4/11] mlx4: use new txqueue timeout argument config: sparc64-allmodconfig (attached as .config) compiler: sparc64-linux-gcc (GCC) 7.5.0 reproduce: wget

We used to queue tx packets in sk_receive_queue, this is less efficient since it requires spinlocks to synchronize between producer and consumer. This patch tries to address this by: - switch from sk_receive_queue to a skb_array, and resize it when tx_queue_len was changed. - introduce a new proto_ops peek_len which was used for peeking the skb length. - implement a tun version of peek_len

Hi, The fact that apparently the last tigervnc update from upstream was missed triggered me to check for missing updates and packages in 6.3. Here are my results. Sorry for any false positives that might have crept in, but note that some of the 6_x updates actually are updates and not a parsing error. And perhaps an occasional false positive due to having to compare upstream SRPMS vs downstream

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 2 Jun 2014 23:55:15 +0300 > The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: > > Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git

Folks, I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce. Maybe someone has a quick idea. [85109.572032] WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318 [85109.572036] Modules linked in: vhost_net vhost macvtap macvlan tap vfio_ap vfio_mdev mdev vfio_iommu_type1 vfio kvm xt_CHECKSUM ipt_MASQUERADE

Hi, Here is a list of packages for 6.3 for which upstream SRPMS are available but which aren't built on CentOS. i686 only (these *are* being built, but won't show up in a x86_64 ls): xorg-x11-drv-geode xorg-x11-drv-neomagic PPC: iprutils libehca libica librtas libvpd (still available as rpm) lsvpd powerpc-utils ppc64-diag ppc64-utils servicelog yaboot S390: compat-gcc-295 openssl-ibmca

Reposting with actual patches included. The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next for you to fetch changes up to 2ae76693b8bcabf370b981cd00c36cd41d33fabc: vhost:

Reposting with actual patches included. The following changes since commit 96b2e73c5471542cb9c622c4360716684f8797ed: Revert "net/mlx4_en: Use affinity hint" (2014-06-02 00:18:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next for you to fetch changes up to 2ae76693b8bcabf370b981cd00c36cd41d33fabc: vhost:

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

On 20.12.2018 10:12, Ido Schimmel wrote: > +Willem > > On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote: >> Folks, >> >> I got this warning today. I cant tell when and why this happened, so I do not know yet how to reproduce. >> Maybe someone has a quick idea. >> >> [85109.572032] WARNING: CPU: 30 PID: 197360 at