On Wed, 2017-02-01 at 18:29 -0500, Boris Ostrovsky wrote:
>
> I could not convince myself that napi_synchronize() is sufficient here
> (mostly because I am not familiar with napi flow). At the same time I
> would rather not make changes in anticipation of possible disappearance
> of netif_carrier
On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
> We do netif_carrier_off() first thing in xennet_disconnect_backend() and
> the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
> which is guarded by netif_carrier_ok() check.
Oh well, testing netif_carrier_ok() in pac
On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
> rx_refill_timer should be deleted as soon as we disconnect from the
> backend since otherwise it is possible for the timer to go off before
> we get to xennet_destroy_queues(). If this happens we may dereference
> queue->rx.sring which is
On Wed, 2017-01-25 at 16:26 +, Paul Durrant wrote:
> Sowmini points out two vulnerabilities in xen-netfront:
>
> a) The code assumes that skb->len is at least ETH_HLEN.
> b) The code assumes that at least ETH_HLEN octets are in the linear
>port of the socket buffer.
>
> This patch adds te
On Tue, 2016-12-20 at 12:51 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 20, 2016 at 05:44:06PM +, Roger Pau Monné wrote:
> > On Tue, Dec 20, 2016 at 11:47:03AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Dec 20, 2016 at 10:02:19PM +0800, Geliang Tang wrote:
> > > > To make the code
From: Eric Dumazet
On Mon, 2015-08-17 at 16:25 +0200, Sander Eikelenboom wrote:
> Monday, August 17, 2015, 4:21:47 PM, you wrote:
>
> > On Mon, 2015-08-17 at 09:02 -0500, Jon Christopherson wrote:
> >> This is very similar to the behavior I am seeing in this
On Mon, 2015-08-17 at 09:02 -0500, Jon Christopherson wrote:
> This is very similar to the behavior I am seeing in this bug:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=102911
OK, but have you applied the fix ?
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c
On Mon, 2015-08-17 at 11:09 +0200, Sander Eikelenboom wrote:
> Saturday, August 15, 2015, 12:39:25 AM, you wrote:
>
> > On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote:
> >> On 2015-08-13 00:41, Eric Dumazet wrote:
> >> > On Wed, 2015-08-12 at 23:4
On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote:
> On 2015-08-13 00:41, Eric Dumazet wrote:
> > On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote:
> >
> >> Thanks for the reminder, but luckily i was aware of that,
> >> seen enough of your
On Wed, 2015-07-15 at 12:52 +0300, Konstantin Khlebnikov wrote:
> These functions check should_resched() before unlocking spinlock/bh-enable:
> preempt_count always non-zero => should_resched() always returns false.
> cond_resched_lock() worked iff spin_needbreak is set.
Interesting, this definite
On Mon, 2015-07-06 at 19:13 +0800, Bob Liu wrote:
>
> Thank you for the quick fix!
> Tested by rebooting several times and didn't hit this panic any more.
Thanks Bob, I will submit an official patch then ;)
___
Xen-devel mailing list
Xen-devel@lists
On Mon, 2015-07-06 at 11:35 +0100, Julien Grall wrote:
> __in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on
> this code is very limited. Are we sure that one this lock is hold? At
> first glance, I wasn't able to find one.
You could play it safe ;)
diff --git a/net/bridge/br_n
On Mon, 2015-07-06 at 16:26 +0800, Bob Liu wrote:
> Hi,
>
> I tried to run the latest kernel v4.2-rc1, but often got below panic during
> system boot.
>
> [ 42.118983] BUG: unable to handle kernel paging request at 003f
> [ 42.119008] IP: [] __netdev_pick_tx+0x70/0x120
> [ 42.1
On Tue, 2015-06-02 at 10:52 +0100, Wei Liu wrote:
> Hi Eric
>
> Sorry for coming late to the discussion.
>
> On Thu, Apr 16, 2015 at 05:42:16AM -0700, Eric Dumazet wrote:
> > On Thu, 2015-04-16 at 11:01 +0100, George Dunlap wrote:
> >
> > > He suggested that
On Mon, 2015-05-11 at 18:34 -0700, Venkat Venkatsubra wrote:
> In ed1f50c3a ("net: add skb_checksum_setup") some checksum functions
> were introduced in core. Subsequent change b5cf66cd1 ("xen-netfront:
> use new skb_checksum_setup function") made use of those functions to
> replace its own impleme
On Thu, 2015-04-16 at 11:01 +0100, George Dunlap wrote:
> He suggested that after he'd been prodded by 4 more e-mails in which two
> of us guessed what he was trying to get at. That's what I was
> complaining about.
My big complain is that I suggested to test to double the sysctl, which
gave goo
On Thu, 2015-04-16 at 12:39 +0100, George Dunlap wrote:
> On 04/15/2015 07:17 PM, Eric Dumazet wrote:
> > Do not expect me to fight bufferbloat alone. Be part of the challenge,
> > instead of trying to get back to proven bad solutions.
>
> I tried that. I wrote a descript
On Thu, 2015-04-16 at 12:20 +0800, Herbert Xu wrote:
> Eric Dumazet wrote:
> >
> > We already have netdev->gso_max_size and netdev->gso_max_segs
> > which are cached into sk->sk_gso_max_size & sk->sk_gso_max_segs
>
> It is quite dangerous to attempt tri
On Wed, 2015-04-15 at 11:19 -0700, Rick Jones wrote:
> Well, I'm not sure that it is George and Jonathan themselves who don't
> want to change a sysctl, but the customers who would have to tweak that
> in their VMs?
Keep in mind some VM users install custom qdisc, or even custom TCP
sysctls.
On Wed, 2015-04-15 at 19:04 +0100, George Dunlap wrote:
> Maybe you should stop wasting all of our time and just tell us what
> you're thinking.
I think you make me wasting my time.
I already gave all the hints in prior discussions.
Rome was not built in one day.
On Wed, 2015-04-15 at 18:58 +0100, Stefano Stabellini wrote:
> On Wed, 15 Apr 2015, Eric Dumazet wrote:
> > On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
> >
> > > Which means that max(2*skb->truesize, sk->sk_pacing_rate >>10) is
> > &g
On Wed, 2015-04-15 at 10:55 -0700, Rick Jones wrote:
> >
> > Have you tested this patch on a NIC without GSO/TSO ?
> >
> > This would allow more than 500 packets for a single flow.
> >
> > Hello bufferbloat.
>
> Woudln't the fq_codel qdisc on that interface address that problem?
Last time I check
On Wed, 2015-04-15 at 18:41 +0100, George Dunlap wrote:
> So you'd be OK with a patch like this? (With perhaps a better changelog?)
>
> -George
>
> ---
> TSQ: Raise default static TSQ limit
>
> A new dynamic TSQ limit was introduced in c/s 605ad7f18 based on the
> size of actual packets and t
On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
> Which means that max(2*skb->truesize, sk->sk_pacing_rate >>10) is
> *already* larger for Xen; that calculation mentioned in the comment is
> *already* doing the right thing.
Sigh.
1ms of traffic at 40Gbit is 5 MBytes
The reason for the c
On Wed, 2015-04-15 at 18:23 +0100, George Dunlap wrote:
> On 04/15/2015 05:38 PM, Eric Dumazet wrote:
> > My thoughts that instead of these long talks you should guys read the
> > code :
> >
> > /* TCP Small Queues :
> > * C
On Wed, 2015-04-15 at 15:36 +0100, Ian Campbell wrote:
> On Wed, 2015-04-15 at 15:19 +0100, George Dunlap wrote:
> > On Mon, Apr 13, 2015 at 4:03 PM, Malcolm Crossley
> [...]
> > > From a networking point of view, the backend is a switch. Is it OK to
> > > consider the packet to have been transmitt
On Wed, 2015-04-15 at 14:43 +0100, George Dunlap wrote:
> On Mon, Apr 13, 2015 at 2:49 PM, Eric Dumazet wrote:
> > On Mon, 2015-04-13 at 11:56 +0100, George Dunlap wrote:
> >
> >> Is the problem perhaps that netback/netfront delays TX completion?
> >> Would i
On Mon, 2015-04-13 at 14:46 +0100, David Vrabel wrote:
> > And the proof-of-concept patch for idea (b) I used was:
> >
> > @@ -552,6 +552,8 @@ static int xennet_start_xmit(struct sk_buff *skb,
> > struct net_device *dev)
> > goto drop;
> > }
> >
> > +skb_orphan(skb);
> > +
On Mon, 2015-04-13 at 11:56 +0100, George Dunlap wrote:
> Is the problem perhaps that netback/netfront delays TX completion?
> Would it be better to see if that can be addressed properly, so that
> the original purpose of the patch (fighting bufferbloat) can be
> achieved while not degrading perfo
On Thu, 2015-04-09 at 17:36 +0100, Stefano Stabellini wrote:
> A very big difference:
>
> echo 262144 > /proc/sys/net/ipv4/tcp_limit_output_bytes
> brings us much closer to the original performance, the slowdown is just
> 8%
Cool.
>
> echo 1048576 > /proc/sys/net/ipv4/tcp_limit_output_bytes
>
; Through bisection I found that the perf regression is caused by the
> prensence of the following commit in the guest kernel:
>
>
> commit 605ad7f184b60cfaacbc038aa6c55ee68dee3c89
> Author: Eric Dumazet
> Date: Sun Dec 7 12:22:18 2014 -0800
>
> tcp: refine TSO autosizin
On Thu, 2015-03-26 at 16:46 +, Jonathan Davies wrote:
> Network drivers with slow TX completion can experience poor network transmit
> throughput, limited by hitting the sk_wmem_alloc limit check in
> tcp_write_xmit.
> The limit is 128 KB (by default), which means we are limited to two 64 KB s
On Thu, 2015-03-26 at 11:13 +, Jonathan Davies wrote:
> xen-netfront limits transmitted skbs to be at most 44 segments in size.
> However,
> GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
> bytes each. This slight reduction in the size of packets means a slight los
On Sat, 2014-12-20 at 17:55 +1100, Herbert Xu wrote:
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdacf0092d10cd09c (net: less
> interrupt masking in NAPI) required drivers to leave poll_list
> empty if the entire budget is consumed.
>
> We have already had two broken drivers so let's add a che
On Sat, 2014-12-20 at 11:36 +1100, Herbert Xu wrote:
> On Sat, Dec 20, 2014 at 11:23:27AM +1100, Herbert Xu wrote:
> >
> > A similar bug exists in virtio_net.
>
> In order to detect other drivers doing this we should add something
> like this.
>
> -- >8 --
> The commit d75b1ade567ffab085e8adbbdac
On Mon, 2014-11-10 at 16:42 +, David Vrabel wrote:
> On 10/11/14 16:39, Zoltan Kiss wrote:
> >
> > The BUG_ON suggested by Stefan would be still reasonable:
> >
> > BUG_ON(((page-compound_head(page))*PAGE_SIZE)+offset+len >
> > PAGE_SIZE<
> Well, it wouldn't trigger but I don't think it is u
36 matches
Mail list logo
