[Bridge] [PATCH v2 net-next] bridge: Add ability to enable TSO
pagupta at redhat.com
Fri Jan 9 19:10:13 UTC 2015
> >> Currently a bridge device turns off TSO feature if no bridge ports
> >> support it. We can always enable it, since packets can be segmented on
> >> ports by software as well as on the bridge device.
> >> This will reduce the number of packets processed in the bridge.
> >> Signed-off-by: Toshiaki Makita <makita.toshiaki at lab.ntt.co.jp>
> >> ---
> >> v2: Use an existing helper function.
> >> net/bridge/br_if.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> >> index ed307db..81e49fb 100644
> >> --- a/net/bridge/br_if.c
> >> +++ b/net/bridge/br_if.c
> >> @@ -424,6 +424,7 @@ netdev_features_t br_features_recompute(struct
> >> net_bridge
> >> *br,
> >> features = netdev_increment_features(features,
> >> p->dev->features, mask);
> >> }
> >> + features = netdev_add_tso_features(features, mask);
> > Just a doubt. Are we inducing latency if source has traffic at very low
> > rate.
> > I mean by default do we need it?
> Is your concern tcp_tso_should_defer() in tcp_write_xmit()?
> If so, since TSO packet is created by GSO even without this patch, this
> should not increase latency there.
> This patch just delays the point of software segmentation from the
> bridge device to its port.
I think now I got your point.
> Toshiaki Makita
> 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
More information about the Bridge