Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1)

Issue 4664057: Netdevice queue feedback support

Can't Edit
Can't Publish+Mail
Start Review
Created:
11 years ago by Ruben Merz
Modified:
10 years, 4 months ago
CC:
ns-3-reviews_googlegroups.com
Visibility:
Public.

Description

Dear all, here is the draft of the netdevice queue support. For some context information, see http://groups.google.com/group/ns-3-reviews/browse_thread/thread/6359c7c94a334f03/ The current patchset contains (a) the API addition to netdevice and (b) an implementation for Wifi scenarios. The patches 003-* and 004-* at http://code.nsnam.org/rmerz/ns-3-netdev-mq/ contain the test code. In particular, I would need feedback/help on the QueueState structure definition (i.e., am I doing it the right way). My objective is to have this feature merged in ns-3.12. Thanks for your help and time. Ruben

Patch Set 1 : Netdevice queue support #

Total comments: 5
Unified diffs Side-by-side diffs Delta from patch set Stats (+603 lines, -7 lines) Patch
M src/bridge/model/bridge-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/bridge/model/bridge-net-device.cc View 1 chunk +20 lines, -0 lines 0 comments Download
M src/csma/model/csma-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/csma/model/csma-net-device.cc View 1 chunk +20 lines, -0 lines 0 comments Download
M src/emu/model/emu-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/emu/model/emu-net-device.cc View 1 chunk +19 lines, -0 lines 0 comments Download
M src/internet/model/loopback-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/internet/model/loopback-net-device.cc View 1 chunk +20 lines, -0 lines 0 comments Download
M src/lte/model/lte-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/lte/model/lte-net-device.cc View 1 chunk +19 lines, -1 line 0 comments Download
M src/mesh/model/mesh-point-device.h View 1 chunk +4 lines, -0 lines 0 comments Download
M src/mesh/model/mesh-point-device.cc View 1 chunk +19 lines, -0 lines 0 comments Download
M src/network/model/net-device.h View 2 chunks +23 lines, -0 lines 5 comments Download
A src/network/model/queue-state.h View 1 chunk +32 lines, -0 lines 0 comments Download
M src/network/utils/simple-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/network/utils/simple-net-device.cc View 1 chunk +20 lines, -0 lines 0 comments Download
M src/network/wscript View 1 chunk +1 line, -0 lines 0 comments Download
M src/openflow/model/openflow-switch-net-device.h View 1 chunk +4 lines, -0 lines 0 comments Download
M src/point-to-point/model/point-to-point-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/point-to-point/model/point-to-point-net-device.cc View 1 chunk +19 lines, -1 line 0 comments Download
M src/spectrum/model/aloha-noack-net-device.h View 1 chunk +4 lines, -2 lines 0 comments Download
M src/spectrum/model/aloha-noack-net-device.cc View 1 chunk +19 lines, -1 line 0 comments Download
M src/spectrum/model/non-communicating-net-device.h View 1 chunk +4 lines, -2 lines 0 comments Download
M src/spectrum/model/non-communicating-net-device.cc View 1 chunk +19 lines, -0 lines 0 comments Download
M src/tap-bridge/model/tap-bridge.h View 1 chunk +4 lines, -0 lines 0 comments Download
M src/tap-bridge/model/tap-bridge.cc View 1 chunk +20 lines, -0 lines 0 comments Download
M src/uan/model/uan-net-device.h View 1 chunk +4 lines, -0 lines 0 comments Download
M src/uan/model/uan-net-device.cc View 1 chunk +20 lines, -0 lines 0 comments Download
M src/virtual-net-device/model/virtual-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/virtual-net-device/model/virtual-net-device.cc View 1 chunk +19 lines, -0 lines 0 comments Download
M src/wifi/model/dca-txop.h View 2 chunks +7 lines, -0 lines 0 comments Download
M src/wifi/model/dca-txop.cc View 5 chunks +24 lines, -0 lines 0 comments Download
M src/wifi/model/edca-txop-n.h View 2 chunks +6 lines, -0 lines 0 comments Download
M src/wifi/model/edca-txop-n.cc View 5 chunks +24 lines, -0 lines 0 comments Download
M src/wifi/model/regular-wifi-mac.h View 3 chunks +11 lines, -0 lines 0 comments Download
M src/wifi/model/regular-wifi-mac.cc View 5 chunks +61 lines, -0 lines 0 comments Download
M src/wifi/model/wifi-mac.h View 2 chunks +7 lines, -0 lines 0 comments Download
M src/wifi/model/wifi-mac-queue.h View 1 chunk +1 line, -0 lines 0 comments Download
M src/wifi/model/wifi-mac-queue.cc View 1 chunk +9 lines, -0 lines 0 comments Download
M src/wifi/model/wifi-net-device.h View 2 chunks +9 lines, -0 lines 0 comments Download
M src/wifi/model/wifi-net-device.cc View 2 chunks +45 lines, -0 lines 0 comments Download
M src/wimax/model/wimax-net-device.h View 1 chunk +5 lines, -0 lines 0 comments Download
M src/wimax/model/wimax-net-device.cc View 1 chunk +21 lines, -0 lines 0 comments Download

Messages

Total messages: 10
Tom Henderson
Is there a plan for allowing qdiscs someday in the NetDevice? We have previously documented ...
10 years, 11 months ago (2011-07-26 14:30:00 UTC) #1
Mathieu Lacage
I am sorry if this has been discussed before but I reviewed this carefully based ...
10 years, 9 months ago (2011-09-14 06:47:43 UTC) #2
Frederic U
On 2011/09/14 06:47:43, Mathieu Lacage wrote: > I am sorry if this has been discussed ...
10 years, 9 months ago (2011-09-14 07:49:33 UTC) #3
Frederic U
On 2011/09/14 07:49:33, Frederic U wrote: > On 2011/09/14 06:47:43, Mathieu Lacage wrote: > > ...
10 years, 9 months ago (2011-09-16 14:56:42 UTC) #4
Ruben Merz
On 2011/07/26 14:30:00, Tom Henderson wrote: > Is there a plan for allowing qdiscs someday ...
10 years, 9 months ago (2011-09-20 19:09:24 UTC) #5
Ruben Merz
On 2011/09/14 06:47:43, Mathieu Lacage wrote: > I am sorry if this has been discussed ...
10 years, 9 months ago (2011-09-20 21:23:25 UTC) #6
Ruben Merz
[snip] > The big difference with the proposed NetDevice patch is that these methods deal ...
10 years, 9 months ago (2011-09-20 21:37:12 UTC) #7
Tom Henderson
> > > http://codereview.appspot.com/4664057/diff/2001/src/network/model/net-device.h#newcode347 > > src/network/model/net-device.h:347: */ > > Why is this needed? Can't ...
10 years, 9 months ago (2011-09-21 13:44:12 UTC) #8
Mathieu Lacage
On 2011/09/20 21:23:25, Ruben Merz wrote: > On 2011/09/14 06:47:43, Mathieu Lacage wrote: > > ...
10 years, 4 months ago (2012-02-24 08:27:24 UTC) #9
ruben.merz
10 years, 4 months ago (2012-02-24 11:17:54 UTC) #10
On 2012/02/24 08:27:24, Mathieu Lacage wrote:
> On 2011/09/20 21:23:25, Ruben Merz wrote:
> > On 2011/09/14 06:47:43, Mathieu Lacage wrote:
> > > I am sorry if this has been discussed before but I reviewed this carefully
> > based
> > > on the latest kernel headers. The biggest differences I see here are:
> > >    1) the Linux kernel allows the driver to decide which queue to use to
> > output
> > > a specific packet _but_ it is allowed to communicate this information to
the
> > > higher level layers. i.e., PickTxQueue would take a Ptr<Packet> and return
a
> > > queue index.
> > >    2) the linux kernel allows the higher level layers to pick which queue
to
> > use
> > > for a specific packet. They store this in one of the skb fields.
> > > 
> > > So, what is the impact from the perspective of integrating a linux kernel
ip
> > > stack on top of this ? I think that it is pretty much nil because the only
> > user
> > > of this API in the linux kernel is the 802.11 stack (the packet scheduling
> API
> > > has a similarly-named function select_queue but it uses to manage the
> > scheduler
> > > queues, not the device queues).
> > > 
> > > So, I think that the above is good. It would be really nice if frederic
> could
> > > try it out to make sure it is ok because this has a fairly large API
impact.
> > > 
> > >
> http://codereview.appspot.com/4664057/diff/2001/src/network/model/net-device.h
> > > File src/network/model/net-device.h (right):
> > > 
> > >
> >
>
http://codereview.appspot.com/4664057/diff/2001/src/network/model/net-device....
> > > src/network/model/net-device.h:347: */
> > > On 2011/07/26 14:30:00, Tom Henderson wrote:
> > > > Why is this needed?  Can't GetNQueues() and GetQueueState() provide the
> same
> > > > information?  
> > > 
> > > +1
> > 
> > Please see my earlier answer to Tom.
> > 
> > >
> >
>
http://codereview.appspot.com/4664057/diff/2001/src/network/model/net-device....
> > > src/network/model/net-device.h:353: * queue index.
> > > On 2011/07/26 14:30:00, Tom Henderson wrote:
> > > > Why not return the QueueState also in the callback, to avoid the client
> > > needing
> > > > to call back into the device with GetQueueState()?
> > > 
> > > In general, I think that it is better to make such callbacks just query
the
> > > object that generated the event for anything they need. i.e., in this
case,
> > what
> > > you need is to provide at least one extra argument that is the
> Ptr<NetDevice>
> > on
> > > which the event occured.
> > 
> > I'm afraid I don't really understand what you are getting at.
> 
> The callback needs an extra argument, the Ptr<NetDevice> itself. The callback
> can then call GetQueueState if needed. In general, it is better to make
> notification listeners not be notified of the exact kind of state change. It
is
> better to just notify them that the state changed and that they need to adjust
> their behavior accordingly. Two reasons for this:
>   - This makes the notification code easier to write.
>   - the listening code in general is too complicated to write to handle
> incremental changes to the state. Most serious listeners never try to
calculate
> the delta. They just calculate the new state.

I see, do you know a good example in the ns-3 code base?
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b