> > > >> > >> 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@xxxxxxxxxxxxx> > >> --- > >> 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()? yes. > 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. Thanks, Pankaj > > Thanks, > Toshiaki Makita > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
