On Friday, 14 May 2021 13:35:32 CEST Linus Lüssing wrote:
> On Fri, May 14, 2021 at 10:28:53AM +0200, Sven Eckelmann wrote:
> > On Tuesday, 27 April 2021 20:45:27 CEST Linus Lüssing wrote:
> > > - * The skb is not consumed, so the caller should make sure that the
> > > - * skb is freed.
> > > + *
On Fri, May 14, 2021 at 10:28:53AM +0200, Sven Eckelmann wrote:
> On Tuesday, 27 April 2021 20:45:27 CEST Linus Lüssing wrote:
> > - * The skb is not consumed, so the caller should make sure that the
> > - * skb is freed.
> > + * This call clones the given skb, hence the caller needs to take into
On Tuesday, 27 April 2021 20:45:27 CEST Linus Lüssing wrote:
> - * The skb is not consumed, so the caller should make sure that the
> - * skb is freed.
> + * This call clones the given skb, hence the caller needs to take into
> + * account that the data segment of the original skb might not be
> +
Currently we schedule a broadcast packet like:
3x: [ [(re-)queue] --> for(hard-if): maybe-transmit ]
The intention of queueing a broadcast packet multiple times is to
increase robustness for wireless interfaces. However on interfaces
which we only broadcast on once the queueing induces an
