Message ID | 1367249009.8964.312.camel@edumazet-glaptop |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
On Mon, 2013-04-29 at 08:23 -0700, Eric Dumazet wrote: > On Mon, 2013-04-29 at 17:27 +0300, Claudiu Manoil wrote: > > Hi, > > > > Unfortunately fixing this the other way around would imply changes > > in both xmit and clean_tx, and additional overhead in clean_tx. > > On xmit skb->len gets incremented with FCB_LEN and/or TXPAL_LEN, > > on a case by case basis. This would imply to add extra checks on > > clean_tx to identify whether only FCB_LEN has been added, or > > FCB+TXPAL or neither, all these just to report the bytes on wire > > for BQL. > > Does BQL really need to measure the bytes-on-wire or the bytes consumed > > for buffering? > > Yes. > > What about : > > diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c > index 2375a01..bb727e1 100644 > --- a/drivers/net/ethernet/freescale/gianfar.c > +++ b/drivers/net/ethernet/freescale/gianfar.c > @@ -2065,6 +2065,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) > u32 bufaddr; > unsigned long flags; > unsigned int nr_frags, nr_txbds, length, fcb_length = GMAC_FCB_LEN; > + unsigned int len; > > /* TOE=1 frames larger than 2500 bytes may see excess delays > * before start of transmission. > @@ -2130,7 +2131,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) > } > > /* Update transmit stats */ > - tx_queue->stats.tx_bytes += skb->len; > + len = skb->len; Idea is to use this value in TX completion. If at tx completion skb->len might be different, then store the true skb->len in skb->cb[] -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-04-29 at 08:23 -0700, Eric Dumazet wrote: > > Does BQL really need to measure the bytes-on-wire or the bytes consumed > > for buffering? > > Yes. I meant, bytes on wire. If it was bytes consumed for buffering, we would use skb->truesize here. Anyway, I am not sure your fix is enough if VLAN is used for example. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/29/2013 6:28 PM, Eric Dumazet wrote: > On Mon, 2013-04-29 at 08:23 -0700, Eric Dumazet wrote: >> On Mon, 2013-04-29 at 17:27 +0300, Claudiu Manoil wrote: >>> Hi, >>> >>> Unfortunately fixing this the other way around would imply changes >>> in both xmit and clean_tx, and additional overhead in clean_tx. >>> On xmit skb->len gets incremented with FCB_LEN and/or TXPAL_LEN, >>> on a case by case basis. This would imply to add extra checks on >>> clean_tx to identify whether only FCB_LEN has been added, or >>> FCB+TXPAL or neither, all these just to report the bytes on wire >>> for BQL. >>> Does BQL really need to measure the bytes-on-wire or the bytes consumed >>> for buffering? >> >> Yes. >> >> What about : >> >> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c >> index 2375a01..bb727e1 100644 >> --- a/drivers/net/ethernet/freescale/gianfar.c >> +++ b/drivers/net/ethernet/freescale/gianfar.c >> @@ -2065,6 +2065,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) >> u32 bufaddr; >> unsigned long flags; >> unsigned int nr_frags, nr_txbds, length, fcb_length = GMAC_FCB_LEN; >> + unsigned int len; >> >> /* TOE=1 frames larger than 2500 bytes may see excess delays >> * before start of transmission. >> @@ -2130,7 +2131,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) >> } >> >> /* Update transmit stats */ >> - tx_queue->stats.tx_bytes += skb->len; >> + len = skb->len; Already tried this change in xmit, but it breaks the UDP/TCP cases (eg. ftp). Due to (skb->ip_summed == CHECKSUM_PARTIAL) condition FCB is added on xmit (skb->len increased with FCB_LEN only), and Tx completion does not make this check. > Idea is to use this value in TX completion. > > If at tx completion skb->len might be different, then store the true > skb->len in skb->cb[] > Interesting but non-trivial, I think. Is this allowed? I mean, doesn't the net stack overwrite this field? Thanks, Claudiu -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-04-29 at 18:52 +0300, Claudiu Manoil wrote: > Interesting but non-trivial, I think. Is this allowed? I mean, doesn't > the net stack overwrite this field? Each layer is allowed to overwrite skb->cb[] Some network drivers already do. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c index 2375a01..bb727e1 100644 --- a/drivers/net/ethernet/freescale/gianfar.c +++ b/drivers/net/ethernet/freescale/gianfar.c @@ -2065,6 +2065,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) u32 bufaddr; unsigned long flags; unsigned int nr_frags, nr_txbds, length, fcb_length = GMAC_FCB_LEN; + unsigned int len; /* TOE=1 frames larger than 2500 bytes may see excess delays * before start of transmission. @@ -2130,7 +2131,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) } /* Update transmit stats */ - tx_queue->stats.tx_bytes += skb->len; + len = skb->len; + tx_queue->stats.tx_bytes += len; tx_queue->stats.tx_packets++; txbdp = txbdp_start = tx_queue->cur_tx; @@ -2231,7 +2233,7 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev) lstatus |= BD_LFLAG(TXBD_CRC | TXBD_READY) | skb_headlen(skb); } - netdev_tx_sent_queue(txq, skb->len); + netdev_tx_sent_queue(txq, len); /* We can work in parallel with gfar_clean_tx_ring(), except * when modifying num_txbdfree. Note that we didn't grab the lock