Re: [LEDE-DEV] [PATCH] kernel: Enable fadvise on older kernels.

[rosenp]

On Fri, 2017-11-17 at 09:30 +0100, John Crispin wrote:
> 
> On 12/11/17 01:50, Rosen Penev wrote:
> > Any chance of this being backported to LEDE stable?
> 
> should be ok, send a patch please
> 
Not quite sure what you mean. The patch applies cleanly. I'll resend
one based on the lede-17.01 branch.
>  John
> 
> > 
> > On Sat, Nov 11, 2017 at 4:49 PM, Rosen Penev 
> > wrote:
> > > Backport of 56342ee2bcbf9bf8918a01045471c7bb7faa1596 for older
> > > kernels.
> > > 
> > > Signed-off-by: Rosen Penev 
> > > ---
> > >   target/linux/generic/config-3.18 | 2 +-
> > >   target/linux/generic/config-4.4  | 2 +-
> > >   2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/target/linux/generic/config-3.18
> > > b/target/linux/generic/config-3.18
> > > index 1e3f0b5abe..4909fa0cde 100644
> > > --- a/target/linux/generic/config-3.18
> > > +++ b/target/linux/generic/config-3.18
> > > @@ -90,7 +90,7 @@ CONFIG_32BIT=y
> > >   # CONFIG_ADM6996_PHY is not set
> > >   # CONFIG_ADM8211 is not set
> > >   # CONFIG_ADT7316 is not set
> > > -# CONFIG_ADVISE_SYSCALLS is not set
> > > +CONFIG_ADVISE_SYSCALLS=y
> > >   # CONFIG_ADXRS450 is not set
> > >   CONFIG_AEABI=y
> > >   # CONFIG_AFFS_FS is not set
> > > diff --git a/target/linux/generic/config-4.4
> > > b/target/linux/generic/config-4.4
> > > index 1c0af9597f..23ed22d4c3 100644
> > > --- a/target/linux/generic/config-4.4
> > > +++ b/target/linux/generic/config-4.4
> > > @@ -82,7 +82,7 @@ CONFIG_32BIT=y
> > >   # CONFIG_ADM6996_PHY is not set
> > >   # CONFIG_ADM8211 is not set
> > >   # CONFIG_ADT7316 is not set
> > > -# CONFIG_ADVISE_SYSCALLS is not set
> > > +CONFIG_ADVISE_SYSCALLS=y
> > >   # CONFIG_ADXRS450 is not set
> > >   CONFIG_AEABI=y
> > >   # CONFIG_AFFS_FS is not set
> > > --
> > > 2.13.6
> > > 
> > 
> > ___
> > Lede-dev mailing list
> > Lede-dev@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] otrx: fix memory leak in otrx_create_append_zeros

[rosenp]

On Thu, 2017-11-16 at 10:15 +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> A "free" call was missing after allocating a buffer.
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  package/utils/otrx/src/otrx.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/package/utils/otrx/src/otrx.c
> b/package/utils/otrx/src/otrx.c
> index 1c3ffd915b..ac39fefc06 100644
> --- a/package/utils/otrx/src/otrx.c
> +++ b/package/utils/otrx/src/otrx.c
> @@ -266,9 +266,12 @@ static ssize_t otrx_create_append_zeros(FILE
> *trx, size_t length) {
>  
>   if (fwrite(buf, 1, length, trx) != length) {
>   fprintf(stderr, "Couldn't write %zu B to %s\n",
> length, trx_path);
> + free(buf);
>   return -EIO;
>   }
>  
> + free(buf);
alternatively, could do

unsigned int l = fwrite(buf, 1, length, trx);
free(buf);
if (l != length) {
 ...

no real difference.
> +
>   return length;
>  }
>  

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/4] otrx: print and return errno if fopen fails

[rosenp]

On Thu, 2017-11-16 at 10:15 +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Signed-off-by: Rafał Miłecki 
> ---
>  package/utils/otrx/src/otrx.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/package/utils/otrx/src/otrx.c
> b/package/utils/otrx/src/otrx.c
> index 0d99cd39e3..1c3ffd915b 100644
> --- a/package/utils/otrx/src/otrx.c
> +++ b/package/utils/otrx/src/otrx.c
> @@ -170,8 +170,8 @@ static int otrx_check(int argc, char **argv) {
>  
>   trx = fopen(trx_path, "r");
>   if (!trx) {
> - fprintf(stderr, "Couldn't open %s\n", trx_path);
> - err = -EACCES;
> + err = -errno;
> + fprintf(stderr, "Couldn't open %s: %d\n", trx_path,
> err);
>   goto out;
>   }
>  
> @@ -233,11 +233,13 @@ static ssize_t otrx_create_append_file(FILE
> *trx, const char *in_path) {
>   size_t bytes;
>   ssize_t length = 0;
>   uint8_t buf[1024];
> + int err;
>  
>   in = fopen(in_path, "r");
>   if (!in) {
> - fprintf(stderr, "Couldn't open %s\n", in_path);
> - return -EACCES;
> + err = -errno;
> + fprintf(stderr, "Couldn't open %s: %d\n", in_path,
> err);
> + return err;
>   }
>  
>   while ((bytes = fread(buf, 1, sizeof(buf), in)) > 0) {
> @@ -333,8 +335,8 @@ static int otrx_create(int argc, char **argv) {
>  
>   trx = fopen(trx_path, "w+");
>   if (!trx) {
> - fprintf(stderr, "Couldn't open %s\n", trx_path);
> - err = -EACCES;
> + err = -errno;
> + fprintf(stderr, "Couldn't open %s: %d\n", trx_path,
> err);
>   goto out;
>   }
>   fseek(trx, curr_offset, SEEK_SET);
> @@ -449,8 +451,8 @@ static int otrx_extract_copy(FILE *trx, size_t
> offset, size_t length, char *out_
>  
>   out = fopen(out_path, "w");
>   if (!out) {
> - fprintf(stderr, "Couldn't open %s\n", out_path);
> - err = -EACCES;
> + err = -errno;
> + fprintf(stderr, "Couldn't open %s: %d\n", out_path,
> err);
>   goto out;
>   }
>  
> @@ -505,8 +507,8 @@ static int otrx_extract(int argc, char **argv) {
>  
>   trx = fopen(trx_path, "r");
>   if (!trx) {
> - fprintf(stderr, "Couldn't open %s\n", trx_path);
> - err = -EACCES;
> + err = -errno;
> + fprintf(stderr, "Couldn't open %s: %d\n", trx_path,
> err);
>   goto out;
>   }

why not use %m? eg: fprintf(stderr, "Couldn't open %s: %m\n", trx_path)
>  

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] procd: Remove unnecessary memset calls.

[rosenp]

Tested compile size difference. Saves 32 bytes. ¯\_(ツ)_/¯

On Tue, 2017-11-07 at 12:05 -0800, Rosen Penev wrote:
> Changes allocation to calloc and {} as needed.
> 
> Signed-off-by: Rosen Penev 
> ---
>  inittab.c  | 6 ++
>  plug/hotplug.c | 7 ++-
>  2 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/inittab.c b/inittab.c
> index 21172f7..c27c324 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -284,8 +284,7 @@ void procd_inittab(void)
>  
>   regcomp(_inittab, "([a-zA-Z0-9]*):([a-zA-Z0-9]*):([a-zA-
> Z0-9]*):(.*)", REG_EXTENDED);
>   line = malloc(LINE_LEN);
> - a = malloc(sizeof(struct init_action));
> - memset(a, 0, sizeof(struct init_action));
> + a = calloc(1, sizeof(struct init_action));
>  
>   while (fgets(line, LINE_LEN, fp)) {
>   char *tags[TAG_PROCESS + 1];
> @@ -322,8 +321,7 @@ void procd_inittab(void)
>   if (add_action(a, tags[TAG_ACTION]))
>   continue;
>   line = malloc(LINE_LEN);
> - a = malloc(sizeof(struct init_action));
> - memset(a, 0, sizeof(struct init_action));
> + a = calloc(1, sizeof(struct init_action));
>   }
>  
>   fclose(fp);
> diff --git a/plug/hotplug.c b/plug/hotplug.c
> index 49c177f..6e55f67 100644
> --- a/plug/hotplug.c
> +++ b/plug/hotplug.c
> @@ -434,12 +434,10 @@ static void handle_button_complete(struct
> blob_attr *msg, struct blob_attr *data
>   if (!name)
>   return;
>  
> - b = malloc(sizeof(*b));
> + b = calloc(1, sizeof(*b));
>   if (!b)
>   return;
>  
> - memset(b, 0, sizeof(*b));
> -
>   b->data = malloc(blob_pad_len(data));
>   b->name = strdup(name);
>   b->seen = timeout;
> @@ -584,11 +582,10 @@ void hotplug_last_event(uloop_timeout_handler
> handler)
>  
>  void hotplug(char *rules)
>  {
> - struct sockaddr_nl nls;
> + struct sockaddr_nl nls = {};
>   int nlbufsize = 512 * 1024;
>  
>   rule_file = strdup(rules);
> - memset(,0,sizeof(struct sockaddr_nl));
>   nls.nl_family = AF_NETLINK;
>   nls.nl_pid = getpid();
>   nls.nl_groups = -1;

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ubox: Remove unnecessary memset calls.

[rosenp]

Just retested. This patch lowers size on x86 from 52144 to 52072

On Tue, 2017-11-07 at 12:22 -0800, Rosen Penev wrote:
> Change to calloc instead. Less verbose.
> 
> Signed-off-by: Rosen Penev 
> ---
>  log/syslog.c | 4 +---
>  lsbloader.c  | 3 +--
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/log/syslog.c b/log/syslog.c
> index af6530c..0e1f2a9 100644
> --- a/log/syslog.c
> +++ b/log/syslog.c
> @@ -246,15 +246,13 @@ log_list(int count, struct log_head *h)
>  int
>  log_buffer_init(int size)
>  {
> - struct log_head *_log = malloc(size);
> + struct log_head *_log = calloc(1, size);
>  
>   if (!_log) {
>   fprintf(stderr, "Failed to initialize log buffer
> with size %d\n", log_size);
>   return -1;
>   }
>  
> - memset(_log, 0, size);
> -
>   if (log && ((log_size + sizeof(struct log_head)) < size)) {
>   struct log_head *start = _log;
>   struct log_head *end = ((void*) _log) + size;
> diff --git a/lsbloader.c b/lsbloader.c
> index b40a505..3d980c4 100644
> --- a/lsbloader.c
> +++ b/lsbloader.c
> @@ -78,12 +78,11 @@ static int initd_parse(const char *file)
>   }
>   buffer[len] = '\0';
>  
> - i = malloc(sizeof(struct initd));
> + i = calloc(1, sizeof(struct initd));
>   if (!i) {
>   fprintf(stderr, "failed to alloc initd struct\n");
>   return -1;
>   }
> - memset(i, 0, sizeof(*i));
>  
>   if (!regexec(_provides, buffer, 2, matches, 0))
>   i->name = strndup(buffer + matches[1].rm_so,
> (size_t)matches[1].rm_eo - matches[1].rm_so);

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] umdns: Replace unnecessary memset calls with {}.

[rosenp]

On Wed, 2017-11-08 at 21:17 +0100, Arjen de Korte wrote:
> Citeren Rosen Penev :
> 
> > Less verbose.
> 
> And uses a GCC extension which makes it less portable. ISO C
> forbids  
> empty initializer braces [1]. See for yourself by adding the
> -pedantic  
> flag to your CFLAGS. The correct way to initialize to all-zeros is  
> therefore { 0 }.
> 
> [1] ISO/IEC 9899:201x, paragraph 6.7.9 Initialization, clause 21
> 
> "If there are fewer initializers in a brace-enclosed list than
> there  
> are elements or members
> of an aggregate, or fewer characters in a string literal used to  
> initialize an array of known
> size  than  there  are  elements  in  the  array,  the  remainder  of
>
> the  aggregate  shall  be
> initialized implicitly the same as objects that have static storage
> duration."

I decided to test this with the following program.


#include 
#include 
#include 

int main()
{
struct k {
int h;
int t;
};

struct k z = {5};
printf("%d", z.t);

return 0;
}

0 was printed instead of 5. 
> 
> > Signed-off-by: Rosen Penev 
> > 
> > v2: some of those memset calls are needed. Also replace { 0 } with
> > {}.
> > ---
> >  interface.c | 16 ++--
> >  1 file changed, 6 insertions(+), 10 deletions(-)
> > 
> > diff --git a/interface.c b/interface.c
> > index 7f814d2..deabcbb 100644
> > --- a/interface.c
> > +++ b/interface.c
> > @@ -186,7 +186,7 @@ read_socket4(struct uloop_fd *u, unsigned int
> > events)
> > struct iovec iov[1];
> > char cmsg[CMSG_SPACE(sizeof(struct in_pktinfo)) +  
> > CMSG_SPACE(sizeof(int)) + 1];
> > struct cmsghdr *cmsgptr;
> > -   struct msghdr msg;
> > +   struct msghdr msg = {};
> > socklen_t len;
> > struct sockaddr_in from;
> > int flags = 0, ifindex = -1;
> > @@ -202,7 +202,6 @@ read_socket4(struct uloop_fd *u, unsigned int
> > events)
> > iov[0].iov_base = buffer;
> > iov[0].iov_len = sizeof(buffer);
> > 
> > -   memset(, 0, sizeof(msg));
> > msg.msg_name = (struct sockaddr *) 
> > msg.msg_namelen = sizeof(struct sockaddr_in);
> > msg.msg_iov = iov;
> > @@ -260,7 +259,7 @@ read_socket6(struct uloop_fd *u, unsigned int
> > events)
> > struct iovec iov[1];
> > char cmsg6[CMSG_SPACE(sizeof(struct in6_pktinfo)) +  
> > CMSG_SPACE(sizeof(int)) + 1];
> > struct cmsghdr *cmsgptr;
> > -   struct msghdr msg;
> > +   struct msghdr msg = {};
> > socklen_t len;
> > struct sockaddr_in6 from;
> > int flags = 0, ifindex = -1;
> > @@ -276,7 +275,6 @@ read_socket6(struct uloop_fd *u, unsigned int
> > events)
> > iov[0].iov_base = buffer;
> > iov[0].iov_len = sizeof(buffer);
> > 
> > -   memset(, 0, sizeof(msg));
> > msg.msg_name = (struct sockaddr *) 
> > msg.msg_namelen = sizeof(struct sockaddr_in6);
> > msg.msg_iov = iov;
> > @@ -327,17 +325,16 @@ read_socket6(struct uloop_fd *u, unsigned int
> > events)
> >  static int
> >  interface_mcast_setup4(struct interface *iface)
> >  {
> > -   struct ip_mreqn mreq;
> > +   struct ip_mreqn mreq = {};
> > uint8_t ttl = 255;
> > int no = 0;
> > -   struct sockaddr_in sa = { 0 };
> > +   struct sockaddr_in sa = {};
> > int fd = iface->fd.fd;
> > 
> > sa.sin_family = AF_INET;
> > sa.sin_port = htons(MCAST_PORT);
> > inet_pton(AF_INET, MCAST_ADDR, _addr);
> > 
> > -   memset(, 0, sizeof(mreq));
> > mreq.imr_address.s_addr = iface->v4_addr.s_addr;
> > mreq.imr_multiaddr = sa.sin_addr;
> > mreq.imr_ifindex = iface->ifindex;
> > @@ -368,17 +365,16 @@ interface_mcast_setup4(struct interface
> > *iface)
> >  static int
> >  interface_socket_setup6(struct interface *iface)
> >  {
> > -   struct ipv6_mreq mreq;
> > +   struct ipv6_mreq mreq = {};
> > int ttl = 255;
> > int no = 0;
> > -   struct sockaddr_in6 sa = { 0 };
> > +   struct sockaddr_in6 sa = {};
> > int fd = iface->fd.fd;
> > 
> > sa.sin6_family = AF_INET6;
> > sa.sin6_port = htons(MCAST_PORT);
> > inet_pton(AF_INET6, MCAST_ADDR6, _addr);
> > 
> > -   memset(, 0, sizeof(mreq));
> > mreq.ipv6mr_multiaddr = sa.sin6_addr;
> > mreq.ipv6mr_interface = iface->ifindex;
> 
> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: Switch to No-op for the default scheduler.

[rosenp]

On Wed, 2017-11-08 at 10:27 +0100, Felix Fietkau wrote:
> On 2017-11-08 07:18, John Crispin wrote:
> > j
> > 
> > 
> > On 07/11/17 19:41, Rosen Penev wrote:
> > > most users don't have multithreaded workloads though.
> > > 
> > > On Mon, Nov 6, 2017 at 4:43 PM, Dave Taht  wrote:
> > > > I happen to like deadline schedulers, and at least from a
> > > > kernel
> > > > perspective, we have a very large set of multithreaded
> > > > workloads.
> > > > 
> > > > So I would not make this change without a very serious set of
> > > > benchmarks
> > > > under load showing it makes a difference.
> > > 
> > > ___
> > > Lede-dev mailing list
> > > Lede-dev@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/lede-dev
> > 
> > I fully agree with dave on this one. changing the default scheduler
> > is 
> > not a small change. please provide benchmarks done on typical
> > router HW 
> > if you would like to see this getting merged.
As Felix said, it's just the I/O scheduler. I'm a bit busy for
benchmarks at this time but I have been using noop for a while now and
have noticed no noticeable regressions.
> 
> It's just the I/O scheduler, not the CPU one. It will have zero
> impact
> on typical router workloads. The only thing that might get slower is
> heavy multi-threaded disk I/O, which is probably an extremely rare
> occurence on LEDE. Also, at least according to that linked phoronix
> benchmark, even on some of these workloads, no-op can be competitive
> ;)
> 
> - Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] procd: Remove unnecessary memset calls.

[rosenp]

On Wed, 2017-11-08 at 11:57 +0100, Paul Oranje wrote:
> Both memset() and calloc() have highly optimised implementations, so
> the expected gains with this patch for the allocation of zeroed
> memory will be small at best. As this patch does not fix a bug: why
> is the change "needed" ?
> 
Style changes are strictly speaking not "needed".
> Just curiosity, bye,
> Paul
> 
> > Op 7 nov. 2017, om 21:05 heeft Rosen Penev  het
> > volgende geschreven:
> > 
> > Changes allocation to calloc and {} as needed.
> > 
> > Signed-off-by: Rosen Penev 
> > ---
> > inittab.c  | 6 ++
> > plug/hotplug.c | 7 ++-
> > 2 files changed, 4 insertions(+), 9 deletions(-)
> > 
> > diff --git a/inittab.c b/inittab.c
> > index 21172f7..c27c324 100644
> > --- a/inittab.c
> > +++ b/inittab.c
> > @@ -284,8 +284,7 @@ void procd_inittab(void)
> > 
> > regcomp(_inittab, "([a-zA-Z0-9]*):([a-zA-Z0-9]*):([a-zA-Z0-
> > 9]*):(.*)", REG_EXTENDED);
> > line = malloc(LINE_LEN);
> > -   a = malloc(sizeof(struct init_action));
> > -   memset(a, 0, sizeof(struct init_action));
> > +   a = calloc(1, sizeof(struct init_action));
> > 
> > while (fgets(line, LINE_LEN, fp)) {
> > char *tags[TAG_PROCESS + 1];
> > @@ -322,8 +321,7 @@ void procd_inittab(void)
> > if (add_action(a, tags[TAG_ACTION]))
> > continue;
> > line = malloc(LINE_LEN);
> > -   a = malloc(sizeof(struct init_action));
> > -   memset(a, 0, sizeof(struct init_action));
> > +   a = calloc(1, sizeof(struct init_action));
> > }
> > 
> > fclose(fp);
> > diff --git a/plug/hotplug.c b/plug/hotplug.c
> > index 49c177f..6e55f67 100644
> > --- a/plug/hotplug.c
> > +++ b/plug/hotplug.c
> > @@ -434,12 +434,10 @@ static void handle_button_complete(struct
> > blob_attr *msg, struct blob_attr *data
> > if (!name)
> > return;
> > 
> > -   b = malloc(sizeof(*b));
> > +   b = calloc(1, sizeof(*b));
> > if (!b)
> > return;
> > 
> > -   memset(b, 0, sizeof(*b));
> > -
> > b->data = malloc(blob_pad_len(data));
> > b->name = strdup(name);
> > b->seen = timeout;
> > @@ -584,11 +582,10 @@ void hotplug_last_event(uloop_timeout_handler
> > handler)
> > 
> > void hotplug(char *rules)
> > {
> > -   struct sockaddr_nl nls;
> > +   struct sockaddr_nl nls = {};
> > int nlbufsize = 512 * 1024;
> > 
> > rule_file = strdup(rules);
> > -   memset(,0,sizeof(struct sockaddr_nl));
> > nls.nl_family = AF_NETLINK;
> > nls.nl_pid = getpid();
> > nls.nl_groups = -1;
> > -- 
> > 2.13.6
> > 
> > 
> > ___
> > Lede-dev mailing list
> > Lede-dev@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: Switch to No-op for the default scheduler.

[rosenp]

I haven't made any benchmarks, no. The router that I use is the Turris
Omnia which has pretty fast eMMC instead of NOR, so they probably
wouldn't be useful to compare to the NOR based stuff.

LEDE tends not to write to flash but does write to RAM, which I think
is still impacted by the choice of scheduler. Not sure.

Agree on the space savings part, although admittedly not much. There's
more oppurtunity for space savings but that's beyond the scope of this
patch.

On Sat, 2017-11-04 at 16:18 -0400, Weedy wrote:
> On Nov 4, 2017 3:57 PM, "Rosen Penev"  wrote:
> > No-op uses less CPU compared to deadline. Important since LEDE runs
> > mainly on routers. Getting rid of deadline saved 156 bytes on my
> > vmlinux file.
> > 
> > Tests conducted by Phoronix on the 4.12 kernel indicate that
> > Deadline is slightly slower than No-op, except with multi-threaded
> > workloads.
> 
> Do you have any boot time bench marks? First boot?
> 
> For the amount of IO we need and considering most LEDE images try to
> write nothing to the flash this feels like free space savings...

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ag71xx: Add back napi_complete_done.

[rosenp]

Well that's embarasing :). Forgot to add _done. Not enough coffee.

On Tue, 2017-10-17 at 22:16 +0100, Kevin Darbyshire-Bryant wrote:
> 
> On 17/10/17 21:52, ros...@gmail.com wrote:
> > I'll take your word for it since I have no hardware to test on.
> 
> I'd say it has a huge impact on performance irrespective of hardware 
> 'cos the patch as supplied doesn't actually compile ;-)
> 
> 
>CC  drivers/net/ethernet/atheros/ag71xx/ag71xx_main.o
> drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c: In function 
> 'ag71xx_poll':
> drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c:1163:2: error: too 
> many arguments to function 'napi_complete'
>napi_complete(napi, rx_done);
>^
> In file included from ./include/linux/etherdevice.h:26:0,
>   from
> drivers/net/ethernet/atheros/ag71xx/ag71xx.h:27,
>   from
> drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c:14:
> ./include/linux/netdevice.h:465:20: note: declared here
>   static inline void napi_complete(struct napi_struct *n)
>  ^
> scripts/Makefile.build:293: recipe for target 
> 'drivers/net/ethernet/atheros/ag71xx/ag71xx_main.o' failed
> make[10]: *** [drivers/net/ethernet/atheros/ag71xx/ag71xx_main.o]
> Error 1
> 
> 
> Kevin
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ag71xx: Add back napi_complete_done.

[rosenp]

I'll take your word for it since I have no hardware to test on.

On Tue, 2017-10-17 at 21:44 +0200, Felix Fietkau wrote:
> On 2017-10-17 18:51, Rosen Penev wrote:
> > This should have no impact on the recently discovered performance
> > regression.
> > 
> > Signed-off-by: Rosen Penev 
> 
> When GRO is not used, this makes no difference at all.
> 
> - Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: enable CONFIG_ADVISE_SYSCALLS

[rosenp]

I don't see a change. I still get 6479872 for vmlinux.

On Sat, 2017-10-14 at 18:05 -0700, Florian Fainelli wrote:
> Le 10/14/17 à 17:07, Rosen Penev a écrit :
> > Without this, posix_[fm]advise does not work. This causes issues
> > with btrfs-progs, which uses fadvise to drop caches.
> 
> What's the kernel image size difference w/ and w/o this option? Would
> it
> make sense to expose it under config/Config-kernel.in for instance?
> 
> > 
> > Signed-off-by: Rosen Penev 
> > ---
> >  target/linux/generic/config-4.9 | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/target/linux/generic/config-4.9
> > b/target/linux/generic/config-4.9
> > index 8654357dbf..570efabc7a 100644
> > --- a/target/linux/generic/config-4.9
> > +++ b/target/linux/generic/config-4.9
> > @@ -90,7 +90,7 @@ CONFIG_32BIT=y
> >  # CONFIG_ADM6996_PHY is not set
> >  # CONFIG_ADM8211 is not set
> >  # CONFIG_ADT7316 is not set
> > -# CONFIG_ADVISE_SYSCALLS is not set
> > +CONFIG_ADVISE_SYSCALLS=y
> >  # CONFIG_ADXRS450 is not set
> >  CONFIG_AEABI=y
> >  # CONFIG_AFE4403 is not set
> > 
> 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ramips: Error in RXCSUM setting? Or, performance improvement.

[rosenp]

I received my new mt7621 toy today and noticed something interesting
when playing with ethtool. I use ethtool to remove most offloads in the
driver as offloads increase latency. But something caught my eye. If I
run "ethtool -K eth0 rx off", iperf performance improves from ~350 to
~450. I ran multiple times to make sure. I looked at the code and it
seems that for mt7621, it's supposed to disable RXCSUM but for some
reason it fails. Anyone have any insight into this?

Anyway, here are results in case nobody believes me. Anomalies are also
present for some reason.

rx = on (default).

root@LEDE:/# iperf -e -s

Server listening on TCP port 5001 with pid 1232
TCP window size: 85.3 KByte (default)

[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55880
[ ID]
IntervalTransferBandwidth   Reads   Dist(bin=16.0K)
[  4] 0.00-10.23 sec   730 MBytes   599
Mbits/sec  80411322:274:576:283:167:215:161:5043
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55882
[  5] 0.00-10.23 sec   417 MBytes   342
Mbits/sec  4172117:751:78:34:29:31:32:3100
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55884
[  4] 0.00-10.23 sec   383 MBytes   314
Mbits/sec  4460294:1116:81:87:83:70:84:2645
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55886
[  5] 0.00-10.24 sec   424 MBytes   347
Mbits/sec  5318381:1479:261:140:115:96:93:2753
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55888
[  4] 0.00-10.23 sec   375 MBytes   307
Mbits/sec  4628324:1317:156:85:72:78:78:2518
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55892
[  5] 0.00-10.23 sec   469 MBytes   385
Mbits/sec  4859229:792:130:105:93:85:74:3351
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55894
[  4] 0.00-10.23 sec   385 MBytes   316
Mbits/sec  4372227:1064:110:79:68:75:68:2681
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55896
[  5] 0.00-10.23 sec   365 MBytes   299
Mbits/sec  4724358:1460:175:93:87:72:87:2392
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55900
[  4] 0.00-10.23 sec   368 MBytes   302
Mbits/sec  4653347:1238:151:157:160:135:134:2331
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55902
[  5] 0.00-10.23 sec   679 MBytes   557
Mbits/sec  93402272:401:1382:377:232:300:234:4142
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55904
[  4] 0.00-10.23 sec   406 MBytes   333
Mbits/sec  4314207:829:88:100:86:63:67:2874

rx off.

root@LEDE:/# ethtool -K eth0 rx off
root@LEDE:/# iperf -e -s

Server listening on TCP port 5001 with pid 1224
TCP window size: 85.3 KByte (default)

[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55930
[ ID]
IntervalTransferBandwidth   Reads   Dist(bin=16.0K)
[  4] 0.00-10.23 sec   568 MBytes   466
Mbits/sec  196313180:6239:10139:59:6:2:0:6
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55940
[  5] 0.00-10.23 sec   520 MBytes   426
Mbits/sec  163002111:3702:9653:531:145:55:36:67
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55942
[  4] 0.00-10.23 sec   573 MBytes   470
Mbits/sec  172101954:2241:12278:663:65:5:4:0
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55944
[  5] 0.00-10.23 sec   530 MBytes   434
Mbits/sec  185023268:5288:9772:168:3:0:2:1
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55946
[  4] 0.00-10.24 sec   541 MBytes   443
Mbits/sec  177073066:2646:11882:103:0:0:0:10
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55948
[  5] 0.00-10.23 sec   570 MBytes   467
Mbits/sec  171662053:2517:11497:1089:6:2:0:2
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55950
[  4] 0.00-10.23 sec   543 MBytes   446
Mbits/sec  168262718:3605:9600:697:8:8:4:186
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55952
[  5] 0.00-10.23 sec   568 MBytes   466
Mbits/sec  171872004:2412:11973:792:4:2:0:0
[  4] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55954
[  4] 0.00-10.24 sec   581 MBytes   476
Mbits/sec  164251503:2227:10757:1891:28:14:4:1
[  5] local 192.168.1.1 port 5001 connected with 192.168.1.130 port
55956
[  5] 0.00-10.23 sec   541 MBytes   443
Mbits/sec  161891861:2487:11090:748:0:2:1:0

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: Add GRO support to ag71xx

[rosenp]

After a bit more research, it turns out this change is really boring.
Eric Dumazet did this for many ethernet drivers early this year.

As far as TSO goes, no idea how to even go about that. As an
interesting side note, TSO support broke mv643xx_eth for a while.

On Sun, 2017-09-03 at 19:10 -0700, Florian Fainelli wrote:
> Le 09/03/17 à 15:46, ros...@gmail.com a écrit :
> > That's...way better than I expected given how minimal my changes
> > are.
> > 
> > For some context, the ag71xx driver is special in that it does not
> > seem
> > to do any hardware offloading to the NIC.
> > 
> > As far as I understand this change, GRO takes 1500 MTU packets and
> > packs then into 64Kb blocks which the kernel then processes.
> > 
> > I would be curious if anyone can do latency comparisons before this
> > change and after. I do know this driver to have lower latency than
> > others due to lack of offloads.
> > 
> > I guess all that's left is to add GSO support to the driver. That
> > seems
> > like a lot more work than a three line change though. ¯\_(ツ)_/¯
> 
> You could look into adding software TSO:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co
> mmit/drivers/net/ethernet/marvell/mv643xx_eth.c?id=3ae8f4e0b98b640aad
> f410c21185ccb6b5b02351
> 
> this makes a huge difference with mv643xx_eth. There were a number of
> fixes on top of this initial commit but I would be curious to see
> what
> it gives you with ag71xx
> 
> > 
> > On Sun, 2017-09-03 at 23:16 +0200, Christian Lamparter wrote:
> > > On Sunday, September 3, 2017 11:35:46 AM CEST Rosen Penev wrote:
> > > > On a TL-WN710N, this patch increases iperf performance from
> > > > ~92.5
> > > > to ~93.5 mbps. Keep in mind the WN710N is a 100mbps device. I
> > > > expect greater numbers from gigabit devices.
> > > > 
> > > > Signed-off-by: Rosen Penev 
> > > > ---
> > > 
> > > I've done a quick test of the patch on my WD Range Extender.
> > > (It has a Atheros AR9344 rev 2 SoC @ CPU:560.000MHz,
> > > DDR:400.000MHz
> > > The PHY is a AR8035, which supports 1 GBit/s Links)
> > > 
> > > The range extender (DUT) was running iperf3 server in both tests.
> > > Another desktop PC was acting as the iperf3 client.
> > > 
> > > without the patch:
> > > 
> > > Connecting to host range-extender, port 5201
> > > [  4] local 192.168.8.7 port 51518 connected to 192.168.8.204
> > > port
> > > 5201
> > > [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
> > > [  4]   0.00-1.00   sec  23.5 MBytes   197 Mbits/sec0105
> > > KBytes
> > > [  4]   1.00-2.00   sec  23.7 MBytes   199 Mbits/sec0105
> > > KBytes
> > > [  4]   2.00-3.00   sec  23.6 MBytes   198 Mbits/sec0105
> > > KBytes
> > > [  4]   3.00-4.00   sec  23.0 MBytes   193 Mbits/sec0105
> > > KBytes
> > > [  4]   4.00-5.00   sec  23.4 MBytes   197 Mbits/sec0105
> > > KBytes
> > > [  4]   5.00-6.00   sec  23.3 MBytes   195 Mbits/sec0105
> > > KBytes
> > > [  4]   6.00-7.00   sec  23.4 MBytes   196 Mbits/sec0105
> > > KBytes
> > > [  4]   7.00-8.00   sec  23.6 MBytes   198 Mbits/sec0105
> > > KBytes
> > > [  4]   8.00-9.00   sec  23.1 MBytes   194 Mbits/sec0105
> > > KBytes
> > > [  4]   9.00-10.00  sec  22.1 MBytes   185 Mbits/sec0105
> > > KBytes
> > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > [ ID] Interval   Transfer Bandwidth   Retr
> > > [  4]   0.00-10.00  sec   233 MBytes   195
> > > Mbits/sec0 sender
> > > [  4]   0.00-10.00  sec   232 MBytes   195
> > > Mbits/sec  receiver
> > > 
> > > iperf Done.
> > > 
> > > with the patch (gro enabled - this is done by default):
> > > 
> > > Connecting to host range-extender, port 5201
> > > [  4] local 192.168.8.7 port 52004 connected to 192.168.8.204
> > > port
> > > 5201
> > > [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
> > > [  4]   0.00-1.00   sec  32.7 MBytes   274 Mbits/sec0106
> > > KBytes   
> > > [  4]   1.00-2.00   sec  32.6 MBytes   274 Mbits/sec0106
> > > KBytes   
> > > [  4]   2.00-3.00   sec  32.4 MBytes   272 Mbits/sec0106
> > > KBytes   
> > > [  4]   3.00-4.00   sec  32.3 MBytes   271 Mbits/sec0106
> > > KBytes   
> > > [  4]   4.00-5.00   sec  32.5 MBytes   273 Mbits/sec0106
> > > KBytes   
> > > [  4]   5.00-6.00   sec  32.5 MBytes   273 Mbits/sec0106
> > > KBytes   
> > > [  4]   6.00-7.00   sec  32.6 MBytes   273 Mbits/sec0106
> > > KBytes   
> > > [  4]   7.00-8.00   sec  32.4 MBytes   272 Mbits/sec0106
> > > KBytes   
> > > [  4]   8.00-9.00   sec  32.6 MBytes   273 Mbits/sec0106
> > > KBytes   
> > > [  4]   9.00-10.00  sec  31.4 MBytes   264 Mbits/sec0106
> > > KBytes   
> > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > [ ID] Interval   Transfer Bandwidth   Retr
> > > [  4]   0.00-10.00  sec   

Re: [LEDE-DEV] [PATCH] ar71xx: Add GRO support to ag71xx

[rosenp]

That's...way better than I expected given how minimal my changes are.

For some context, the ag71xx driver is special in that it does not seem
to do any hardware offloading to the NIC.

As far as I understand this change, GRO takes 1500 MTU packets and
packs then into 64Kb blocks which the kernel then processes.

I would be curious if anyone can do latency comparisons before this
change and after. I do know this driver to have lower latency than
others due to lack of offloads.

I guess all that's left is to add GSO support to the driver. That seems
like a lot more work than a three line change though. ¯\_(ツ)_/¯

On Sun, 2017-09-03 at 23:16 +0200, Christian Lamparter wrote:
> On Sunday, September 3, 2017 11:35:46 AM CEST Rosen Penev wrote:
> > On a TL-WN710N, this patch increases iperf performance from ~92.5
> > to ~93.5 mbps. Keep in mind the WN710N is a 100mbps device. I
> > expect greater numbers from gigabit devices.
> > 
> > Signed-off-by: Rosen Penev 
> > ---
> 
> I've done a quick test of the patch on my WD Range Extender.
> (It has a Atheros AR9344 rev 2 SoC @ CPU:560.000MHz, DDR:400.000MHz
> The PHY is a AR8035, which supports 1 GBit/s Links)
> 
> The range extender (DUT) was running iperf3 server in both tests.
> Another desktop PC was acting as the iperf3 client.
> 
> without the patch:
> 
> Connecting to host range-extender, port 5201
> [  4] local 192.168.8.7 port 51518 connected to 192.168.8.204 port
> 5201
> [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
> [  4]   0.00-1.00   sec  23.5 MBytes   197 Mbits/sec0105
> KBytes
> [  4]   1.00-2.00   sec  23.7 MBytes   199 Mbits/sec0105
> KBytes
> [  4]   2.00-3.00   sec  23.6 MBytes   198 Mbits/sec0105
> KBytes
> [  4]   3.00-4.00   sec  23.0 MBytes   193 Mbits/sec0105
> KBytes
> [  4]   4.00-5.00   sec  23.4 MBytes   197 Mbits/sec0105
> KBytes
> [  4]   5.00-6.00   sec  23.3 MBytes   195 Mbits/sec0105
> KBytes
> [  4]   6.00-7.00   sec  23.4 MBytes   196 Mbits/sec0105
> KBytes
> [  4]   7.00-8.00   sec  23.6 MBytes   198 Mbits/sec0105
> KBytes
> [  4]   8.00-9.00   sec  23.1 MBytes   194 Mbits/sec0105
> KBytes
> [  4]   9.00-10.00  sec  22.1 MBytes   185 Mbits/sec0105
> KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth   Retr
> [  4]   0.00-10.00  sec   233 MBytes   195
> Mbits/sec0 sender
> [  4]   0.00-10.00  sec   232 MBytes   195
> Mbits/sec  receiver
> 
> iperf Done.
> 
> with the patch (gro enabled - this is done by default):
> 
> Connecting to host range-extender, port 5201
> [  4] local 192.168.8.7 port 52004 connected to 192.168.8.204 port
> 5201
> [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
> [  4]   0.00-1.00   sec  32.7 MBytes   274 Mbits/sec0106
> KBytes   
> [  4]   1.00-2.00   sec  32.6 MBytes   274 Mbits/sec0106
> KBytes   
> [  4]   2.00-3.00   sec  32.4 MBytes   272 Mbits/sec0106
> KBytes   
> [  4]   3.00-4.00   sec  32.3 MBytes   271 Mbits/sec0106
> KBytes   
> [  4]   4.00-5.00   sec  32.5 MBytes   273 Mbits/sec0106
> KBytes   
> [  4]   5.00-6.00   sec  32.5 MBytes   273 Mbits/sec0106
> KBytes   
> [  4]   6.00-7.00   sec  32.6 MBytes   273 Mbits/sec0106
> KBytes   
> [  4]   7.00-8.00   sec  32.4 MBytes   272 Mbits/sec0106
> KBytes   
> [  4]   8.00-9.00   sec  32.6 MBytes   273 Mbits/sec0106
> KBytes   
> [  4]   9.00-10.00  sec  31.4 MBytes   264 Mbits/sec0106
> KBytes   
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth   Retr
> [  4]   0.00-10.00  sec   324 MBytes   272
> Mbits/sec0 sender
> [  4]   0.00-10.00  sec   324 MBytes   272
> Mbits/sec  receiver
> 
> iperf Done.
> 
> (range-extender) # ethtool -K eth0 gro off
> 
> Connecting to host range-extender, port 5201
> [  4] local 192.168.8.7 port 52120 connected to 192.168.8.204 port
> 5201
> [ ID] Interval   Transfer Bandwidth   Retr  Cwnd
> [  4]   0.00-1.00   sec  24.8 MBytes   208 Mbits/sec0105
> KBytes   
> [  4]   1.00-2.00   sec  23.6 MBytes   198 Mbits/sec0105
> KBytes   
> [  4]   2.00-3.00   sec  24.5 MBytes   206 Mbits/sec0105
> KBytes   
> [  4]   3.00-4.00   sec  23.9 MBytes   201 Mbits/sec0105
> KBytes   
> [  4]   4.00-5.00   sec  24.6 MBytes   207 Mbits/sec0105
> KBytes   
> [  4]   5.00-6.00   sec  24.7 MBytes   207 Mbits/sec0105
> KBytes   
> [  4]   6.00-7.00   sec  24.5 MBytes   206 Mbits/sec0105
> KBytes   
> [  4]   7.00-8.00   sec  24.0 MBytes   201 Mbits/sec0105
> KBytes   
> [  4]   8.00-9.00   sec  24.3 MBytes   204 Mbits/sec0105
> KBytes   
> [  4]   9.00-10.00  sec  24.5 MBytes   206 

Re: [LEDE-DEV] b43 support for AC chipsets like BCM4360 and BCM4352?

[rosenp]

Based on kernel activity, this driver is not under active development.

And yes, avoid.

On Tue, 2017-08-01 at 00:42 +0200, Baptiste Jonglez wrote:
> Hi,
> 
> As far as I can tell, the b43 driver does not support AC chipsets
> like
> BCM4352, BCM4360, BCM4366.  Support for these is marked BROKEN
> upstream.
> 
> This means that a few devices supported by LEDE actually have no
> wireless,
> for instance Archer C9 v1, ASUS RT-AC68U, maybe others.  Also, quite
> a lot
> of dual-band devices lack 5 GHz support, because BCM4360 seems to be
> quite
> popular as a second wireless chipset.
> 
> Is there any news regarding AC support in b43, and more generally
> b43-related activity, or should we just avoid these devices?
> 
> Thanks,
> Baptiste
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Generic way to disable Generic Receive Offload (GRO)

[rosenp]

Hmm how about driver side? looking at the source code,
register_netdevice enables GSO and GRO by default. Any way to
explicitly disable it?

On Mon, 2017-05-29 at 14:34 -0700, Florian Fainelli wrote:
> Le 05/29/17 à 13:55, ros...@gmail.com a écrit :
> > So LEDE is using fq_codel by default. On the cake homepage is this
> > little sentence:
> > 
> > "Preliminary indications are that not doing GRO “peeling” is where
> > the
> > first generation of fq_codel enabled 802.11ac routers went wrong in
> > their QoS systems."
> > 
> > On my Archer C7v2, I've been able to observe that by disabling GRO
> > using ethtool, I've been able to get a 1-2ms reduction in my
> > overall
> > latency when browsing the internet.
> > 
> > Anyone know if there is a way to disable GRO without having to
> > install
> > ethtool?
> 
> ethtool just send an ioctl so you can write a few lines of C code
> that
> would do the same thing.
> 
> > 
> > On a side note, the ethernet driver for the Archer needs some love.
> > It's not using the correct API for GRO (using netif_receive_skb
> > instead
> > of napi_gro_receive).
> > 
> > ___
> > Lede-dev mailing list
> > Lede-dev@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/lede-dev
> > 
> 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE/OpenWrt and Open Compute Project (OCP)

[rosenp]

On Wed, 2017-05-03 at 10:37 -0400, Abylay Ospan wrote:
> Hello All,
> 
> I'm working on Facebook's Open Compute CBW (Campus, Branch, and
> Wireless) project [1]. OCP CBW mission is:
> "Closed wireless and branch networking equipment have served well in
> the past but now is the time to democratize wireless networking to
> make it programmable, faster, easier, and less expensive for
> customers
> and give everyone the power of choice like never before"
> 
> We have made some research and choose LEDE/OpenWrt as base system
> (thanks for LEDE/OpenWrt advantages :). Question about relation
> between LEDE and OpenWrt is not clear to me now. Is everybody suggest
> to switch to LEDE codebase ? It should be not big deal as I see.
> Currently I have some kernel patches that can be applied to LEDE (may
> be without modifications).

OpenWRT is for the most part, dead. LEDE is where all the new
development happens.

> 
> Hardware options is:
> 3 Broadcom based designs (802.11 AC Wave 1)[2]
> 2 Qualcomm based designs (802.11 AC WAVE 2)
> More planned by other H/W ODMs in 2017/18
> 
> All devices is open hardware in some terms.
> 
> I have started github repo for adopting OpenWrt to this hardware:
> https://github.com/aospan/openwrt/commits/ocp
> 
> Currently main AP I'm working on is EdgeCore ECW7220-L [2]. CPU, RAM,
> Flash, Ethernet is supported now. There is also two wifi pci-e
> adapters:
> 01:00.0 Class 0280: 14e4:43a2
> 01:00.0 Class 0280: 14e4:4331
> 
> "14e4:4331" is supported by b43 driver in 2.4GHz only mode (this is
> ok). Second adapter "14e4:43a2" doesn't supported by brcmsmac (this
> adapter is soft-mac). Now I'm trying to make this adapter working
> with
> brcmsmac.
> Also, there is plans to adopt/create solution for modern Software
> Defined Network model based on OpenWRT. All projects will be Open
> Source.
> We are open for new participants. If you are interested please drop
> me
> a message or send reply to ML for public discussion.
> And happily we have possibilities to rise some funds to make some
> tasks payable.
> 
> Links:
>  [1] http://www.opencompute.org/wiki/Networking/CBWCampus2cBranch2CAn
> dWireless
>  [2] http://www.edge-core.com/productsInfo.php?cls=3=19=24;
> id=112
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] MT7621 support Jumbo frames

[rosenp]

Probably was not in the interest of the driver writers. Based on the
copyrights though, it's mostly LEDE/OpenWRT developers. Try modifying
the code to test if jumbo frames work.

On Sun, 2017-04-09 at 21:20 +0200, Jaap Buurman wrote:
> Hello all,
> 
> I found the message below in a conversation from back in August, 2016
> in this mailinglist. I did not find a reply to this question. Has
> there ever been one? Or does anyone else happen to know the answer to
> this question? Thank you very much in advance.
> 
> Yours sincerely,
> 
> Jaap Buurman
> 
> August, 2016 message:
> 
> 
> Hi all,
> 
> in the MT7621 ethernet driver code
> (drivers/net/ethernet/mediatek/soc_mt7621.c) the FE_FLAG_JUMBO_FRAME
> flag is not during the device initialization. This prevents the user
> to set an MTU greater than 1500. Is this correct? Does MT7621 support
> jumbo frames?
> 
> Thanks.
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev