svn commit: r203337 - user/luigi/ipfw3-head/sys/netinet/ipfw
Luigi Rizzo
luigi at FreeBSD.org
Mon Feb 1 10:56:12 UTC 2010
Author: luigi
Date: Mon Feb 1 10:56:12 2010
New Revision: 203337
URL: http://svn.freebsd.org/changeset/base/203337
Log:
small updates to the documentation
Modified:
user/luigi/ipfw3-head/sys/netinet/ipfw/dummynet.txt
Modified: user/luigi/ipfw3-head/sys/netinet/ipfw/dummynet.txt
==============================================================================
--- user/luigi/ipfw3-head/sys/netinet/ipfw/dummynet.txt Mon Feb 1 10:45:23 2010 (r203336)
+++ user/luigi/ipfw3-head/sys/netinet/ipfw/dummynet.txt Mon Feb 1 10:56:12 2010 (r203337)
@@ -84,22 +84,30 @@ USERLAND-KERNEL API (ip_dummynet.h)
contains data about the physical link such as
bandwith, delay, burst size;
- struct dn_profile:
- fields to simulate a delay profile
+ struct dn_fs:
+ describes a flowset, i.e. a template for queues.
+ Main parameters are the scheduler we attach to, a flow_mask,
+ buckets, queue size, plr, weight, and other scheduler-specific
+ parameters.
+
+ struct dn_flow
+ contains information on a flow, including masks and
+ statistics
struct dn_sch:
defines a scheduler (and a link attached to it).
Parameters include scheduler type, sched_mask, number of
buckets, and possibly other scheduler-specific parameters,
- struct dn_fs:
- describes a flowset, i.e. a template for queues.
- Main parameters are the scheduler we attach to, a flow_mask,
- buckets, queue size, plr, weight, and other scheduler-specific
- parameters.
+ struct dn_profile:
+ fields to simulate a delay profile
+
KERNEL REPRESENTATION (ip_dn_private.h)
+ struct mq
+ a queue of mbufs with head and tail.
+
struct dn_queue
individual queue of packets, created by a flowset using
flow_mask and attached to a scheduler instance selected
@@ -189,21 +197,27 @@ Almost all objects in this implementatio
Files
-----
-New dummynet is split in several files.
-Two headers, a file to implement the userland part and some files for the
-kernel side are provided.
-- dn_sched.h is the minimal header that is used to implement
- a scheduler
-- ip_dummynet.h is the main header defining the kenrel-userland API
-- ip_dn_io.c is the main files for the kernel side of dummynet. It contains
- main functions for processing packets, some functions exported to help
- writing new scheduler;
-- ip_dummynet.c cointains module glue and sockopt handlers.
+The dummynet code is split in several files.
+All kernel code is in sys/netinet/ipfw except ip_dummynet.h
+All userland code is in sbin/ipfw.
+Files are
+- sys/netinet/ip_dummynet.h defines the kernel-userland API
+- ip_dn_private.h contains the kernel-specific APIs
+ and data structures
+- dn_sched.h defines the scheduler API
+- ip_dummynet.c cointains module glue and sockopt handlers, with all
+ functions to configure and list objects.
+- ip_dn_io.c contains the functions directly related to packet processing,
+ and run in the critical path. It also contains some functions
+ exported to the schedulers.
+- dn_heap.[ch] implement a binary heap and a generic hash table
+- dn_sched_* implement the various scheduler modules
+
- dummynet.c is the file used to implement the user side of dummynet.
It contains the function to parsing command line, and functions to
show the output of dummynet objects.
Moreover, there are two new file (ip_dummynet_glue.c and ip_fw_glue.c) that
-are used to allow compatibility with the "ipfw" binary from FreeBSd 7.2 and
+are used to allow compatibility with the "ipfw" binary from FreeBSD 7.2 and
FreeBSD 8.
LOCKING
@@ -233,20 +247,56 @@ In perspective we aim at the following:
- the main containers (fshash, schedhash, ...) are protected by
UH_WLOCK.
- TO BE COMPLETED
-
Packet processing
-==============
+=================
A packet enters dummynet through dummynet_io(). We first lookup
-the flowset number in fshash(), then possibly use masks to determine
-queue and scheduler instance, and call the enqueue routine for the
-scheduler.
-If enqueue is successful, we may call dequeue for further processing,
-and possibly return the packet upstream. If the packet does not
-return, it will be sent later according to the scheduler.
+the flowset number in fshash using dn_ht_find(), then find the scheduler
+instance using ipdn_si_find(), then possibly identify the correct
+queue with ipdn_q_find().
+If successful, we call the scheduler's enqueue function(), and
+if needed start I/O on the link calling serve_sched().
+If the packet can be returned immediately, this is done by
+leaving *m0 set. Otherwise, the packet is absorbed by dummynet
+and we simply return, possibly with some appropriate error code.
+
+Reconfiguration
+---------------
+Reconfiguration is the complex part of the system because we need to
+keep track of the various objects and containers.
+At the moment we do not use reference counts for objects so all
+processing must be done under a lock.
+
+The main entry points for configuration is the ip_dn_ctl() handler
+for the IP_DUMMYNET3 sockopt (others are provided only for backward
+compatibility). Modifications to the configuration call do_config().
+The argument is a sequence of blocks each starting with a struct dn_id
+which specifies its content.
+The first dn_id must contain as obj.id the DN_API_VERSION
+The obj.type is DN_CMD_CONFIG (followed by actual objects),
+DN_CMD_DELETE (with the correct subtype and list of objects), or
+DN_CMD_FLUSH.
+
+DN_CMD_CONFIG is followed by objects to add/reconfigure. In general,
+if an object already exists it is reconfigured, otherwise it is
+created in a way that keeps the structure consistent. In detail,
+and starting with the simplest objects
+
+DN_PROFILE <--> config_profile()
+ attach a delay profile to a DN_LINK with the same number.
+ To delete, simply provide a profile with 0 points.
+ XXX is it preserved on link reconfigurations ?
+
+DN_LINK <--> config_link()
+
+==== XXX to be completed ====
+
+DN_FS
+
+DN_SCH
+
+
+
-The reconfiguration routine
----------------------------
The reconfigure routine is called by the system when the flowset ptr_sched_val
number differs from the generation number. This means that a new object is
inserted in the system or a object was deleted and no new packet belonging to
More information about the svn-src-user
mailing list