headers
Hans Schillstrom | 1 Dec 2011 01:52
Favicon

Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark


On Wednesday, November 30, 2011 19:28:15 Pablo Neira Ayuso wrote:
> On Wed, Nov 30, 2011 at 04:27:26PM +0100, Patrick McHardy wrote:
> > On 11/28/2011 10:36 AM, Hans Schillstrom wrote:
> > >>If you don't want to use conntrack in your setup and you want to handle
> > >>fragments, then you have to configure HMARK to calculate the hashing
> > >>based on the network addresses. If you want to fully support fragments,
> > >>then enable conntrack and you can configure HMARK to calculate the
> > >>hashing based on network address + transport bits.
> > >>
> > >>Fix this by removing the fragmentation handling, then assume that
> > >>people can select between two hashing configuration for HMARK. One
> > >>based for network address which is fragment-safe, one that uses the
> > >>transport layer information, that requires conntrack. Otherwise, I
> > >>don't see a sane way to handle this situation.
> > >Correct me if I'm wrong here,
> > >If conntrack is enabled hmark don't see the packet until it is reassembled and
> > >in that case the fragmentation header is removed.
> > >
> > >So, with conntrack HMARK will operate on full packets not fragments
> > >without conntrack ports will not be used on any fragment
> > 
> > Correct.
> 
> To complete what Patrick said. They are collected but not linearized.
> That's why you have to use skb_header_pointer.
OK, thanks
I'll will do that.

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Herbert | 1 Dec 2011 02:04
Picon
Favicon

Re: [PATCH v4 06/10] e1000e: Support for byte queue limits

> whats wrong with using total_tx_bytes or buffer_info->bytecount?  it
> contains the "bytes on the wire" value which will be slightly larger
> than skb->len, but avoids warming the skb->len cacheline unnecessarily.
>

This makes sense.  I made the changes, but the limits computed are
much higher than with using sbk->len.  I suspect there may be a bug in
GSO path.

For instance, in the driver at:

  bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;

I see cases like:

  segs=34, skb_header_len(skb)=70, skb->len=49298 so bytecount=51608

Which seems reasonable... but, I also see things like:

  segs=45, skb_header_len(skb)=1522, skb->len=65226, so bytecount= 132194
                                                      ^^^^
Which doesn't seem right at all.  I am thinking there may be a bug
setting skb->data_len improperly.

Tom
Permalink | Reply | 4 comments |
headers
Maciej Żenczykowski | 1 Dec 2011 02:18
Picon
Gravatar

[PATCH] netconsole: implement ipv4 tos support

From: Maciej Żenczykowski <maze <at> google.com>

Signed-off-by: Maciej Żenczykowski <maze <at> google.com>
---
 Documentation/networking/netconsole.txt |    1 +
 drivers/net/netconsole.c                |   28 ++++++++++++++++++++++++++++
 include/linux/netpoll.h                 |    1 +
 net/core/netpoll.c                      |    4 +++-
 4 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 8d02207..a02374f 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
 <at>  <at>  -94,6 +94,7  <at>  <at>  The interface exposes these parameters of a netconsole target to userspace:
 	remote_ip	Remote agent's IP address		(read-write)
 	local_mac	Local interface's MAC address		(read-only)
 	remote_mac	Remote agent's MAC address		(read-write)
+	tos		TOS byte value to utilize		(read-write)

 The "enabled" attribute is also used to control whether the parameters of
 a target can be updated or not -- you can modify the parameters of only
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index e888202..d24d5df 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
 <at>  <at>  -90,6 +90,7  <at>  <at>  static DEFINE_SPINLOCK(target_list_lock);
  *		remote_ip	(read-write)
  *		local_mac	(read-only)
  *		remote_mac	(read-write)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Stephen Hemminger | 1 Dec 2011 02:34
Favicon

Re: [PATCH] netconsole: implement ipv4 tos support

On Wed, 30 Nov 2011 17:18:50 -0800
Maciej Żenczykowski <zenczykowski <at> gmail.com> wrote:

> From: Maciej Żenczykowski <maze <at> google.com>
> 
> Signed-off-by: Maciej Żenczykowski <maze <at> google.com>

Why make it an option? TOS should always be set to interactive
traffic (like telnet and slogin)
Permalink | Reply | 8 comments |
headers
Tom Herbert | 1 Dec 2011 02:48
Picon
Favicon

Bug in computing data_len in tcp_sendmsg?

I believe that skb->data_len might no be computed correctly in
tcp_sendmsg.  Specifically, when skb_add_data_nocache (or
skb_add_data) is called skb->data_len is not updated (skb_put only
updates skb->len).  This results in the datalen in the head skbuf
being zero so any subsequent uses of the value lead to incorrect
results.  For instance, skb_headlen returns the length of the head
skbu data and not just that of the headers.  If I'm reading this
correctly, it's a pretty fundamental bug.

I don't have a fix for this yet.

Tom
Permalink | Reply | 28 comments |
headers
Maciej Żenczykowski | 1 Dec 2011 03:11
Picon
Gravatar

Re: [PATCH] netconsole: implement ipv4 tos support

> Why make it an option? TOS should always be set to interactive
> traffic (like telnet and slogin)

Because 'interactive' doesn't mean anything.  You don't know what
value of tos defines 'interactive' traffic on my network.
I may also consider network console/debug/dump/etc traffic less
important then say serving web traffic, and thus not even want it to
be considered 'interactive' in the first place.

TOS values are relevant within a LAN/WAN/Organization/AS, but are not
relevant internet-wide.
Almost all AS-boundary gateways/routers will do TOS remarking to their
own internal specifications.

- Maciej
Permalink | Reply | 5 comments |
headers
Stephen Hemminger | 1 Dec 2011 03:27
Favicon

Re: [PATCH] netconsole: implement ipv4 tos support

On Wed, 30 Nov 2011 18:11:32 -0800
Maciej Żenczykowski <zenczykowski <at> gmail.com> wrote:

> > Why make it an option? TOS should always be set to interactive
> > traffic (like telnet and slogin)
> 
> Because 'interactive' doesn't mean anything.  You don't know what
> value of tos defines 'interactive' traffic on my network.
> I may also consider network console/debug/dump/etc traffic less
> important then say serving web traffic, and thus not even want it to
> be considered 'interactive' in the first place.
> 
> TOS values are relevant within a LAN/WAN/Organization/AS, but are not
> relevant internet-wide.
> Almost all AS-boundary gateways/routers will do TOS remarking to their
> own internal specifications.
> 
> - Maciej

Giving the user choice in general is good, but network configuration
is already confusing enough.

Although interpretation of TOS is per organization, in practice the
values are standardized in places like RFC4594. For example, routing protocols
all use IPTOS_PREC_INTERNETCONTROL = 0xc0
Permalink | Reply | 2 comments |
headers
Li Wei | 1 Dec 2011 03:30
Favicon

Re: Is there any necessary to add multicast route for a loopback device?

Hi David,

what's your opinion?

> Hi all,
> 
> I found that since Fedora 15, it use systemd as the 'init'. When systemd start 
> it would config the ipv6 address(::1/128) for 'lo' and start it. While adding 
> this address to 'lo', kernel will call addrconf_add_mroute() to set a multicast
> route for 'lo' with rt->dst.error = -ENETUNREACH. After that, when I send multi-
> cast message, the route subsystem return a route with .error set to NETUNREACH.
> 
> Is there any necessary to add multicast route for a loopback device? 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>
Permalink | Reply | 4 comments |
headers
roy.qing.li | 1 Dec 2011 03:37
Picon

[PATCH] net/core: fix rollback handler in register_netdevice_notifier

From: RongQing.Li <roy.qing.li <at> gmail.com>

Within nested statements, the break statement terminates only the
do, for, switch, or while statement that immediately encloses it,
So replace the break with goto.

Signed-off-by: RongQing.Li <roy.qing.li <at> gmail.com>
---
 net/core/dev.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 278463e..88876fa 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
 <at>  <at>  -1387,7 +1387,7  <at>  <at>  rollback:
 	for_each_net(net) {
 		for_each_netdev(net, dev) {
 			if (dev == last)
-				break;
+				goto outroll;

 			if (dev->flags & IFF_UP) {
 				nb->notifier_call(nb, NETDEV_GOING_DOWN, dev);
 <at>  <at>  -1398,6 +1398,7  <at>  <at>  rollback:
 		}
 	}

+outroll:
 	raw_notifier_chain_unregister(&netdev_chain, nb);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Dumazet | 1 Dec 2011 04:30
Picon

Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior

Le mercredi 30 novembre 2011 à 23:20 +0100, Hagen Paul Pfeifer a écrit :
> This extension can be used to simulate special link layer
> characteristics. Simulate because packet data is not modified, only the
> calculation base is changed to delay a packet based on the original
> packet size and artificial cell information.
> 
> packet_overhead can be used to simulate a link layer header compression
> scheme (e.g. set packet_overhead to -20) or with a positive
> packet_overhead value an additional MAC header can be simulated. It is
> also possible to "replace" the 14 byte Ethernet header with something
> else.
> 
> cell_size and cell_overhead can be used to simulate link layer schemes,
> based on cells, like some TDMA schemes. Another application area are MAC
> schemes using a link layer fragmentation with a (small) header each.
> Cell size is the maximum amount of data bytes within one cell. Cell
> overhead is an additional variable to change the per-cell-overhead (e.g.
> 5 byte header per fragment).
> 
> Example (5 kbit/s, 20 byte per packet overhead, cell-size 100 byte, per
> cell overhead 5 byte):
> 
> 	tc qdisc add dev eth0 root netem rate 5kbit 20 100 5
> 
> Signed-off-by: Hagen Paul Pfeifer <hagen <at> jauu.net>
> ---
> 
> The actual version of packet_len_2_sched_time() address Eric's div/mod
> instruction concerns. I benchmarked the version in the patch with the
> following version:
(Continue reading)

Permalink | Reply | 12 comments |

Gmane