[RFC] Wake-on-LAN flex filters

Most modern Ethernet hardware supports flexible filters for wake-on-LAN,
probably because it's a requirement for certification with Another
Operating System.

This patch implements this feature on e1000 via Ethtool.  The kernel
portion of this code is fairly well polished, but the changes to the
tool are extremely hacky and ugly.  Don't bother to comment on that
portion; if people want this feature either Jeff or I will redo it
correctly.

To create a filter:
# ethtool -F <interface> <filter number> <filter>

where <filter number> can be from 0 - 3 (at least for e1000), and where
filter is a string of hex digits describing what the filtered frame
should look like.  Each byte MUST be represented by two hex digits, and
no whitespace is allowed.  If a particular byte should be ignored by the
filter, represent it with "xx".   

For example:
# ethtool -F eth0 1 00xxxxxxxx11223344567890xx

To show a filter:
# ethtool -f <interface> <filter num>   

To enable WOL filters (after setting one):
# ethtool -s <interface> wol f 

Please review and comment, and thanks.

Re: high latency with TCP connections

Hello!

> 2) a way to take delayed ACKs into account for cwnd growth

This part is OK now, right?

> 1) protection against ACK division

But Linux never had this problem... Congestion window was increased
only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could
break this, but should not). Otherwise, this ACK just advanced snd_una
and nothing more.

This aspect of ABC is crucial for BSD. TCP_NODELAY sockets did not obey
congestion control there. From the very beginning, before slow start
it can send thousands of 1 byte segments.

The only problem of kind "too-aggressive" with Linux was that we could
develop large cwnd sending small segments, and then switch to sending
mss-sized segments. It does not look scary, to be honest. 

Linux had troubles with slow start even before ABC. Actually,
some of applications can suffer of the same syndrome even if ABC disabled.
With ABC it becomes TROUBLE, cwnd has no chances to develop at all.

Probably, aspect 1 of ABC just should be disabled. And the first my suggestion
looks working too.

Alexey
-

Re: [RFC] Enable/Disable VLAN HW filters

Mitch Williams wrote:
> We've had a few internal requests for a way to enable and disable the
> hardware VLAN filter at runtime.  I'm posting it here for discussion and
> to see if anybody else is interested in this feature.
> 
> Originally I had planned to do this as an Ethtool ioctl, but decided
> instead to handle it through the VLAN module.  Ethtool doesn't know
> anything about VLANs at all.
> 
> There are no userspace changes required to support this functionality.
> 
> To disable HW VLAN filtering:
> # vconfig set_flag <VLAN interface> 2 1
> 
> To enable HW VLAN filtering:
> # vconfig set_flag <VLAN interface> 2 0
> 
> At this point (somewhat obviously), it's only implemented on e1000, but
> this ioctl could be easily implemented by other drivers.

Sounds like a good idea to me.

> +	switch (flag) {
> +	case VLAN_FLAG_REORDER:
> +		if (flag_val)
> +			VLAN_DEV_INFO(dev)->flags |= 1;
> +		else
> +			VLAN_DEV_INFO(dev)->flags &= ~1;
> +		break;

LRO fix needed

Ananda, Herbert Xu recently found a problem in the TCP stack
input path for LRO capable receive paths.

The issue is that the receive MSS estimator in
tcp_measure_rcv_mss() uses skb->len for the MSS
estimation.  This is wrong for LRO frames.

Herbert noticed this using Xen which pused TSO frames
on output back into the destination TCP stack on input
so it looks exactly like LRO.

His fix to tcp_measure_rcv_mss() is to use
skb_shared_info(skb)->gso_size if it is non-zero,
else skb->len, in the assignment to "len".

So could you please make the S2io driver LRO path
set skb_shared_info(skb)->gso_size appropriately?
Probably the easiest is to use the length of the
first frag of a multiple frag LRO sequence.

Also, could we have a linux/MAINTAINERS entry added
for the S2io driver?

Thanks.
-
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

Re: LRO fix needed

On Thu, Aug 31, 2006 at 04:42:27PM -0700, David Miller wrote:
> 
> So could you please make the S2io driver LRO path
> set skb_shared_info(skb)->gso_size appropriately?
> Probably the easiest is to use the length of the
> first frag of a multiple frag LRO sequence.

It might be better to set it to the biggest frag you see rather
than the first.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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

Re: NAPI: netif_rx_reschedule() ??

Hello!

> However I'm confused about a couple of things, and there are only two
> uses of netif_rx_reschedule() in the kernel, so I'm a little stuck.

First, do not believe to even single bit of code or docs about
netif_rx_reschedule(). It was used once in the first version of NAPI
for 3com driver (which did not go to mainstream) and was left to rot. 

> 1. What is the intent of the second, 'undo' parameter?  For example,
>    ibmveth.c does
> 
> 	if(ibmveth_rxq_pending_buffer(adapter) && netif_rx_reschedule(netdev, frames_processed))
> 	{
> 		lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
> 		ibmveth_assert(lpar_rc == H_SUCCESS);
> 		more_work = 1;
> 		goto restart_poll;
> 	}
> 
>    but it only does
> 
> 	netdev->quota -= frames_processed;
> 
>    _after_ that block (and the jump back to restart_poll).  So the
>    whole things seems fishy: netdev->quota goes up by the number of
>    frames processed??

It is broken. netdev->quota MUST not be touched after netif_rx_complete().
Authors improved coding style, moving it closer to update of *budget

Re: high latency with TCP connections

From: Alexey Kuznetsov <kuznet <at> ms2.inr.ac.ru>
Date: Fri, 1 Sep 2006 03:29:23 +0400

> > 2) a way to take delayed ACKs into account for cwnd growth
> 
> This part is OK now, right?

This part of ABC is not on by default, and was broken until last week


Test in tcp_slow_start() used to be:

	tp->bytes_acked > 2*tp->mss_cache

but now it is the correct:

	tp->bytes_acked >= 2*tp->mss_cache

It allows to make two congestion window increases from one ACK, when
noticing delayed ACK.

Non-ABC code did not do this, but could figure this kind of thing
out while scanning retransmit queue.

> > 1) protection against ACK division
> 
> But Linux never had this problem... Congestion window was increased
> only when a whole skb is ACKed, flag FLAG_DATA_ACKED. (TSO could
> break this, but should not). Otherwise, this ACK just advanced snd_una
> and nothing more.

[IPSEC]: output mode to take an xfrm state as input param

Against net-2.6.19

cheers,
jamal

  Expose IPSEC modes output path to take an xfrm state as input param.
  This makes it consistent with the input mode processing (which already
  takes the xfrm state as a param).

---
commit 0169ac1c2a64f04deeff3dae704f34e22ae59cb7
tree 8ae315bf21444eec3f845538ac06a080a184a534
parent 28df617d024ac4eaeb51123eea9eda2932466684
author Jamal Hadi Salim <hadi <at> znyx.com> Thu, 31 Aug 2006 19:55:17 -0400
committer Jamal Hadi Salim <hadi <at> jzny2.(none)> Thu, 31 Aug 2006 19:55:17 -0400

 include/net/xfrm.h              |    2 +-
 net/ipv4/xfrm4_mode_transport.c |    4 +---
 net/ipv4/xfrm4_mode_tunnel.c    |    3 +--
 net/ipv4/xfrm4_output.c         |    2 +-
 net/ipv6/xfrm6_mode_ro.c        |    3 +--
 net/ipv6/xfrm6_mode_transport.c |    3 +--
 net/ipv6/xfrm6_mode_tunnel.c    |    3 +--
 net/ipv6/xfrm6_output.c         |    2 +-
 8 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9d366a2..bf8e2df 100644
--- a/include/net/xfrm.h

Re: [IPSEC]: output mode to take an xfrm state as input param

Are you too cool to give "Signed-off-by:" lines?


Please give me one for this patch so I can add it to
net-2.6.19

Thanks.
-
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

Re: [IPSEC]: output mode to take an xfrm state as input param

On Thu, 2006-31-08 at 17:24 -0700, David Miller wrote:
> Are you too cool to give "Signed-off-by:" lines?
> 
> 

Dang. Just too brain congested to give you one ;->

signed-off-by: Jamal Hadi Salim <hadi <at> cyberus.ca>

cheers,
jamal

-
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