lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 13 Aug 2014 16:29:07 -0700 (PDT)
From:	David Miller <>
Subject: Re: [PATCH net-next 3/3] sunvnet: Schedule maybe_tx_wakeup as a
 tasklet from ldc_rx path

From: Sowmini Varadhan <>
Date: Wed, 13 Aug 2014 07:20:10 -0400

> On (08/12/14 21:25), David Miller wrote:
>> However, don't get ahead of yourself.  All I'm saying in the context
>> of reviewing this patch #3 is that you should leave vnet_tx_timeout()
>> alone and just put what you were putting into vnet_tx_timeout() into
>> maybe_tx_wakeup().
> And just leave vnet_tx_timeout() as before (i.e, "XXX implement me"?)?

Yes, and I see this is what you have done.

> Note that, as I pointed out to Raghuram already, doing ldc_disconnect
> does *not* send any reset events. The code may have other missing
> functionality. 

For the caller of ldc_disconnect() the reset is implied, if this is
what you are talking about.

I don't see any value for generating an event the user of the LDC
channel itself generated.

>> So the question is how to manage this on the driver side, and the most
>> natural way I see do this would be to use multiple TX netdev queues
>> and a custom netdev_ops->ndo_select_queue() method which selects the
>> queue based upon the peer that would be selected.
> This might work well for the current sunvnet model (and even
> there, it has limitations- if all the traffic is going out 
> via the switchport to a gateway, you are again back to the 
> head-of-line blocking model).
> But how generally useful is this model? For point-to-multipoint links
> like ethernet, I dont think you actually track one channel per
> peer.  

I don't understand what your concern could be.

Ethernet is a broadcast medium, so all traffic (as far as the NIC is
concerned) goes via the same single queue.

But here we have independent queues leading up to different
destinations, so representing that as independent queues makes

This way, if one non-switch peer goes down, all switch based traffic
will still continue to flow, and vice versa.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists