netdev - Re: VLAN I/F's and TX queue.

lists.openwall.net		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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BE81793.3060905@trash.net>
Date:	Mon, 10 May 2010 16:26:27 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>,
	netdev@...r.kernel.org
Subject: Re: VLAN I/F's and TX queue.

Eric Dumazet wrote:
> Le vendredi 07 mai 2010 à 10:04 +0200, Joakim Tjernlund a écrit :
>> So I did some more testing
>> two nodes A and B connected over a slow link.
>> Create two VLAN's as above and start pinging from A to B
>> with pkg size 9600, start a few(4-10) parallel ping processes.
>>
>> Now I see dropped packages on B, the receiver of pings, and no
>> pkg loss on A.
>>
> 
> dropped on RX path or TX path ?
> 
>> 1) since the link is symmetrical, why do I only see pkg loss
>>    at B?
>>
>> 2) pkg loss in B only manifests on the VLAN's interfaces and
>>    always in pair as if one lost pkg is counted twice?
>>
> 
> Congestion notifications can be stacked since commit cbbef5e183079
> (vlan/macvlan: propagate transmission state to upper layers)
> 
>> 3) I would expect lost pkgs to be accounted on eth0 instead of
>>    the VLAN interface(s) since that is where the pkg is lost, why
>>    isn't it so?
> 
> You try to send packets on eth0.XXX, some are dropped, and accounted for
> on eth0.XXX stats. What is wrong with this ?
> 
> If you want to avoid this, just add queues to your vlans
> 
> ip link add link eth0 eth0.103 txqueuelen 100 type vlan id 103
> 
> Patrick what do you think of special casing NET_XMIT_CN ?

Is the intention just to avoid accounting the packet as dropped?
That seems fine to me since in case of NET_XMIT_CN its actually
not the currently transmitted packet that was dropped.

But part of the intention of the above mentioned patch was actually
to inform higher layers of congestion so they can take action if
desired, which would be defeated by this patch.

> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index b5249c5..c671b1a 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -327,6 +327,8 @@ static netdev_tx_t vlan_dev_hard_start_xmit(struct sk_buff *skb,
>  	len = skb->len;
>  	ret = dev_queue_xmit(skb);
>  
> +	ret = net_xmit_eval(ret);
> +
>  	if (likely(ret == NET_XMIT_SUCCESS)) {
>  		txq->tx_packets++;
>  		txq->tx_bytes += len;
> @@ -353,6 +355,8 @@ static netdev_tx_t vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb,
>  	len = skb->len;
>  	ret = dev_queue_xmit(skb);
>  
> +	ret = net_xmit_eval(ret);
> +
>  	if (likely(ret == NET_XMIT_SUCCESS)) {
>  		txq->tx_packets++;
>  		txq->tx_bytes += len;
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html